Доступ к файлу: откройте сбои для одной программы, но не другого
Это - самая необычная вещь. Я пытаюсь запустить mysqld с другим my.cnf (таким образом, у меня может быть два демона MySQL, работающие без конфликта). Файл является/etc/mysql/my2.cnf, но mysql не откроет его.
Когда я выполняю эту команду:
sudo -u mysql strace /usr/sbin/mysqld --defaults-file=/etc/mysql/my2.cnf
Я вижу это в выводе:
stat("/etc/mysql/my2.cnf", {st_mode=S_IFREG|0644, st_size=3574, ...}) = 0
open("/etc/mysql/my2.cnf", O_RDONLY) = -1 EACCES (Permission denied)
Однако, когда я изменяю команду на:
sudo -u mysql strace cat /etc/mysql/my2.cnf > /dev/null
Я вижу это в выводе:
fstat(1, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
open("/etc/mysql/my2.cnf", O_RDONLY) = 3
Тот же пользователь - тот же вызов ядра - различные результаты!
Я проверил полномочия файла - и расширил полномочия:
# ls -l $PWD/my2.cnf
-rw-r--r-- 1 root root 3574 2011-07-08 10:04 /etc/mysql/my2.cnf
# lsattr $PWD/my2.cnf
-----------------e- /etc/mysql/my2.cnf
Я получаю бит некоторой частью AppArmour или SELinux? Я не видел ничего как этот в журналах (включая daemon.log, системный журнал или сообщения).
Как я решаю эту проблему?
1 ответ
Ничей отвеченный, таким образом, я скажу то, что я узнал.
Проблема короче говоря следующая: когда файл /etc/mysql/my2.cnf получают доступ cat, мы видим это:
open("/etc/mysql/my2.cnf", O_RDONLY) = 3
Однако, когда mysqld выполняет тот же вызов, это получает другой ответ:
open("/etc/mysql/my2.cnf", O_RDONLY) = -1 EACCES (Permission denied)
Таким образом, ответ кладут в ядре. Что-то в ядре дифференцировалось между вызовом для открытия (2) cat и mysqld. Единственной вещью, которая пришла на ум, был AppArmor.
Поиск пакетов в системе поднял несколько связанные с AppArmor. Список файлов в пакетах поднял команду apparmor_status; выполнение этого показало это mysqld действительно покрыт под AppArmor:
# apparmor_status
apparmor module is loaded.
6 profiles are loaded.
6 profiles are in enforce mode.
/sbin/dhclient3
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/connman/scripts/dhclient-script
/usr/sbin/mysqld
/usr/sbin/ntpd
/usr/sbin/tcpdump
0 profiles are in complain mode.
3 processes have profiles defined.
3 processes are in enforce mode :
/usr/sbin/mysqld (22699)
/usr/sbin/mysqld (6808)
/usr/sbin/ntpd (2800)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
Чтение страниц справочника для apparmor (7) показало, что профили были сохранены в /etc/apparmor.d; рассмотрение этого каталога поднимает файл usr.sbin.mysqld. Это оказывается файлом для изменения.
Изменение файла просто, копируя записи для исходных стандартных каталогов и файлов и превращая их в новые каталоги и файлы. После того как это сделано, активируйте новую конфигурацию a service apparmor restart.
Я никогда не видел сообщений в системном журнале об "аудите" (от AppArmor). Причина этого состояла в том, что сообщения перешли в /var/log/audit/audit.log вместо syslog или messages. Этот файл содержал записи как они:
type=APPARMOR_DENIED msg=audit(1310141055.025:256): operation="mknod" pid=28765 parent=28764 profile="/usr/sbin/mysqld" requested_mask="c::" de
nied_mask="c::" fsuid=104 ouid=104 name="/var/log/mysql2/error.log"
type=APPARMOR_DENIED msg=audit(1310141055.025:257): operation="open" pid=28765 parent=28764 profile="/usr/sbin/mysqld" requested_mask="r::" den
ied_mask="r::" fsuid=104 ouid=104 name="/var/lib/mysql2/mysql/plugin.frm"
type=APPARMOR_DENIED msg=audit(1310141055.035:258): operation="open" pid=28765 parent=28764 profile="/usr/sbin/mysqld" requested_mask="rw::" de
nied_mask="rw::" fsuid=104 ouid=104 name="/var/lib/mysql2/ibdata1"
type=APPARMOR_DENIED msg=audit(1310141097.085:259): operation="open" pid=28780 parent=28779 profile="/usr/sbin/mysqld" requested_mask="::r" den
ied_mask="::r" fsuid=104 ouid=0 name="/etc/mysql/my2.cnf"
type=APPARMOR_DENIED msg=audit(1310141177.636:260): operation="open" pid=28841 parent=28840 profile="/usr/sbin/mysqld" requested_mask="::r" den
ied_mask="::r" fsuid=104 ouid=0 name="/etc/mysql/my2.cnf"
type=APPARMOR_DENIED msg=audit(1310141614.953:261): operation="open" pid=28903 parent=28902 profile="/usr/sbin/mysqld" requested_mask="::r" denied_mask="::r" fsuid=104 ouid=0 name="/etc/mysql/my2.cnf"
type=APPARMOR_DENIED msg=audit(1310141665.113:262): operation="open" pid=28916 parent=28915 profile="/usr/sbin/mysqld" requested_mask="::r" denied_mask="::r" fsuid=104 ouid=0 name="/etc/mysql/my2.cnf"
type=APPARMOR_DENIED msg=audit(1310141739.863:263): operation="open" pid=28926 parent=28925 profile="/usr/sbin/mysqld" requested_mask="::r" denied_mask="::r" fsuid=104 ouid=0 name="/etc/mysql/my2.cnf"
type=APPARMOR_DENIED msg=audit(1310142253.323:264): operation="open" pid=28962 parent=19377 profile="/usr/sbin/mysqld" requested_mask="::r" denied_mask="::r" fsuid=104 ouid=0 name="/etc/mysql/conf2.d/"
Это доказывает мое обоснование и расследование: AppArmor отклонял открытое (2) запросы.
Теперь, когда я знал, что искать, я нашел записи в блоге, касающиеся этого - одна статья от полностью назад в 2008.