Привет всем
Имеется Centos система, которая грузится с флешки, которая в свою очередь в режиме RO. На флешке лежит ext3fs.img с основной файловой системой, при старте в initrd на нее накладывается snapshot через dmsetup, изменения все в tmpfs. Все работает во многих инсталляциях, однако недавно столкнулся с проблемой: при большой нагрузке количество изменений превышает допустимый предел, корневая система помечается как сбойная, соответственно сервер приходит к нерабочему состоянию. В общем-то это проблема известная, описана в мануалах, но при маленькой нагрузке это не мешало работать устройствам годами без проблем. А при большой нагрузке количества блоков на 512мб снапшоте хватает лишь на неделю работы максимум. Можно, конечно увеличить размер снапшота, но это тупиковый путь. Тем более что больше 512 мб свободного места в общем-то не требуется для нормальной работы.

Решил перейти на unionfs. В принципе все заработало. В стандартный шапкин initrd добавил такое:

if [ -n "$EXT3FS" ] ; then
    if [ "$quiet" != "1" ] ; then
        echo "setting up embedded ext3 fs "
    fi

    mkdir /rw
    mkdir /ro
    mkdir /union
    mkdir -m 777 /tmp
        set up new /dev/root symlink
        rm -f /dev/root
    
    mount -t tmpfs -o size=512M tmpfs /rw
    mount -o loop /sysroot/ext3fs.img /ro
    umount -l /sysroot
    unionfs -o cow /rw=RW:/ro=RO /sysroot
        ln -s /sysroot /dev/root
fi

Система загрузилась почти нормально. Почти - потому что какая-то засада с правами на файлы. Я долго гуглил, но так и не понял, в чем проблема. У меня только косвенные данные. Например, не запустился mysql:

140202 07:04:22  mysqld started
/usr/libexec/mysqld: Can't create/write to file '/tmp/ib6IxvMO' (Errcode: 13)
140202  7:04:23  InnoDB: Error: unable to create temporary file; errno: 13
140202  7:04:23 [ERROR] bdb:  /var/lib/mysql: Permission denied
140202  7:04:23 [ERROR] bdb:  /var/lib/mysql/log.0000000001: Permission denied
140202  7:04:23 [ERROR] bdb:  PANIC: Permission denied
140202  7:04:23 [ERROR] bdb:  PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
140202  7:04:23 [ERROR] bdb:  fatal region error detected; run recovery
140202  7:04:23 [ERROR] bdb:  /var/lib/mysql: Permission denied
140202  7:04:23 [ERROR] Can't start server : Bind on unix socket: Permission denied
140202  7:04:23 [ERROR] Do you already have another mysqld server running on socket: /var/lib/mysql/mysql.sock

Апач тоже с бедой, на любой запрос отвечает:

[Sun Feb 02 07:08:51 2014] [error] [client 127.0.0.1] (13)Permission denied: access to /reset.php denied
[Sun Feb 02 07:08:58 2014] [error] [client 192.168.0.66] (13)Permission denied: access to / denied
[Sun Feb 02 07:08:59 2014] [error] [client 192.168.0.66] (13)Permission denied: access to /favicon.ico denied

сделать su mysql нельзя, пишет:

# su mysql
su: /bin/bash: Permission denied

любая программа, использующая sudo под рутом пишет:

bash-3.2# save
sudo: can't open /etc/sudoers: Permission denied

хотя раньше такого не было и если запуститься со старым initrd то все будет как надо.

При всем при этом права доступа к корню или к этим файлам имеются и полностью аналогичны таковым с рабочей системы:

bash-3.2# ls -l /etc/sudoers
-r--r----- 1 root root 4652 Feb  2 07:04 /etc/sudoers
bash-3.2# ls -l /
total 20
drwxr-xr-x  1 root     root       80 Feb  2 07:04 bin
drwxr-xr-x 12 root     root     4140 Feb  2 07:06 dev
drwxr-xr-x  1 root     root     1140 Feb  2 07:05 etc
drwxrwxrwx  5 asterisk asterisk 4096 Dec 31  1969 flash
drwxr-xr-x  1 root     root     4096 Mar 29  2007 home
drwxr-xr-x  1 root     root      180 Feb  2 07:04 lib
drwxr-xr-x  1 root     root     4096 Mar 29  2007 media
drwxr-xr-x  1 root     root     4096 Mar 29  2007 mnt
dr-xr-xr-x 99 root     root        0 Feb  2 02:03 proc
drwxr-x---  1 root     root       60 Feb  2 07:04 root
drwxr-xr-x  1 root     root      260 Feb  2 07:04 sbin
drwxr-xr-x 11 root     root        0 Feb  2 02:03 sys
drwxrwxrwx  7 asterisk asterisk 4096 Feb  1 22:48 tftpboot
drwxrwxrwx  1 root     root      160 Feb  2 07:10 tmp
drwxr-xr-x  1 root     root      160 Feb  2 07:04 usr
drwxr-xr-x  1 root     root      200 Feb  2 07:04 var

Что может быть? Куда копать? что проверить?
Большое спасибо за советы!

2

akluchnikov пишет:

drwxrwxrwx  1 root     root      160 Feb  2 07:10 tmp

как минимум на /tmp должен быть sticky бит... так что с правами не всё в порядке, т.е., судя по симптомам, не сохраняются все три дополнительных бита...

и почему unionfs, а не aufs? я думал первая уже отправлена на свалку...

95% процентов проблем находятся между клавиатурой и стулом.

3 (02.02.2014 20:16:37 отредактировано akluchnikov)

Я так полагаю что sticky бит особо и не нужен. Без него же программы имеют доступ в tmp. unionfs потому что это Centos 5.2, довольно старая сборка. Не знаю, есть ли aufs для нее. Но если unionfs будет нормально работать, то какая разница?

В общем заметил что проблема со всеми программами, которые запускаются от имени других пользователей. В остальном вроде проблем нету.

4 (02.02.2014 20:39:23 отредактировано Fat-Zer)

akluchnikov пишет:

так полагаю что sticky бит особо и не нужен. Без него же программы имеют доступ в tmp.

он нужен для секьюрности, чтобы разные пользователи не смогли удалять файлы друг друга...

akluchnikov пишет:

unionfs потому что это Centos 5.2, довольно старая сборка.

unionfs ещё старше...

akluchnikov пишет:

Не знаю, есть ли aufs для нее. Но если unionfs будет нормально работать, то какая разница?

если будет, то пожалуйста... хотя мне всё равно ни какой разницы...

akluchnikov пишет:

В общем заметил что проблема со всеми программами, которые запускаются от имени других пользователей.

говорю же, наверняка, steuid/setgid/sticky биты не сохраняет... почему, как и можно ли исправить — копай доки unionfs'а...  у меня подозрение, что это сделано специально из-за проблем с безопасностью...

95% процентов проблем находятся между клавиатурой и стулом.

5 (02.02.2014 20:42:17 отредактировано akluchnikov)

Fat-Zer пишет:

он нужен для секьюрности, чтобы разные пользователи не смогли удалять файлы друг друга..

на сервере нет других пользователей-людей, только программы

Fat-Zer пишет:

говорю же, наверняка, steuid/setgid/sticky биты не сохраняет... почему, как и можно ли исправить — копай доки unionfs'а...

не так уж их много этих доков.

AUFS для шапки что-то нету. Да и требует пересборки ядра. Это, конечно, можно сделать, но все-же гимор лишний... Не сделали ее по-людски модулем ядра...

6

доп. биты сохраняются, создал несколько файлов и попробовал:

-rwsr-sr-t 1 root root     0 Feb  2 12:20 fileaaa
-rwSr-Sr-- 1 root root     0 Feb  2 12:20 filebbb
-rw-r-Sr-- 1 root root     0 Feb  2 12:20 fileccc

Сравнил права с эталонной системой - совпадают...

7 (02.02.2014 21:43:55 отредактировано Fat-Zer)

akluchnikov пишет:

AUFS для шапки что-то нету. Да и требует пересборки ядра. Это, конечно, можно сделать, но все-же гимор лишний... Не сделали ее по-людски модулем ядра...

Там первая что ли? вторая по-идее тоже только в виде патча на ядро существует...

akluchnikov пишет:

доп. биты сохраняются, создал несколько файлов и попробовал:

а на /bin/su setuid не стоит? Может тогда сам образ плохой?

akluchnikov пишет:

на сервере нет других пользователей-людей, только программы

программы тоже пользователи... ИРЛ конечно никому до этого дела нет, но паранойя при настройке вещь полезная =)

95% процентов проблем находятся между клавиатурой и стулом.

8 (02.02.2014 22:06:00 отредактировано akluchnikov)

Fat-Zer пишет:

а на /bin/su setuid не стоит? Может тогда сам образ плохой?

Для сравнения

ls -l /bin
-rwsr-xr-x 1 root root  24120 May 24  2008 su
-rwsr-xr-x 1 root root  24120 May 24  2008 su
-rwsr-xr-x 1 root root  30092 Jun 22  2012 su

На разных системах одинаково. Последнее на гораздо более новой версии системы (еще не в продакшене).
Образ ща проверю (подменю файл на эталонный).

UPD: с эталонным образом результат тот же....

9

akluchnikov пишет:

-rwsr-xr-x 1 root root  24120 May 24  2008 su

это на системе с unionfs'ом и su всё равно не работает? гм... тогда идей пока больше нет...

95% процентов проблем находятся между клавиатурой и стулом.