Вопрос или проблема
На моей системе Fedora с отключенным модулем selinux unconfined (поэтому selinux работает в очень строгом режиме) я постоянно получаю следующее сообщение:
Feb 16 23:20:11 stodi.digitalkingdom.org systemd[2227]: Failed to open /dev/mapper/mydev device, ignoring: Permission denied
Указанное устройство – это зашифрованное устройство, доступное для каждого пользователя. Я уверен, что проблема с правами доступа связана с selinux, и я могу сам с этим разобраться. Мой вопрос в том, почему systemd пытается обращаться к этому устройству около 26 раз в день? Что он вообще делает, обращаясь к этому устройству? Как я могу остановить это? Я не хочу, чтобы он вообще трогал это устройство.
ДОБАВЛЕНО 1: Частота появления этой проблемы значительно варьировалась с течением времени; число “26” было случайным днем недавно, но вчера это произошло 8834 раза. -_-; Кажется, это происходило каждые 5 минут в течение большинства дня, и каждый раз это происходило около 20 раз.
Теперь я знаю, почему это происходит много раз одновременно: это процессы systemd на уровне пользователя. Когда я смотрю на PID, указанный в ошибке с течением времени, есть множество одиночных процессов, но большинство из них из ограниченного набора PID, которые:
rlpowell@stodi> for num in 2195 2196 2197 2199 2200 2201 2202 2204 2205 2206 2207 2209 2210 2221 2222 2224 2225 2226 2227 2366
do
ps afux | grep '[ ]'$num'[ ]'
done
1000 2195 0.0 0.0 262436 10192 ? Ss 2024 11:41 /usr/lib/systemd/systemd --user
1001 2196 0.0 0.0 264192 7528 ? Ss 2024 4:45 /usr/lib/systemd/systemd --user
1009 2197 0.0 0.0 262288 6256 ? Ss 2024 4:38 /usr/lib/systemd/systemd --user
1027 2199 0.0 0.0 263348 6292 ? Ss 2024 4:51 /usr/lib/systemd/systemd --user
1039 2200 0.0 0.0 262340 7012 ? Ss 2024 4:47 /usr/lib/systemd/systemd --user
1048 2201 0.0 0.0 262476 7504 ? Ss 2024 4:53 /usr/lib/systemd/systemd --user
1049 2202 0.0 0.0 263872 6676 ? Ss 2024 4:42 /usr/lib/systemd/systemd --user
1052 2204 0.0 0.0 261156 8200 ? Ss 2024 4:39 /usr/lib/systemd/systemd --user
1065 2205 0.0 0.0 261304 6708 ? Ss 2024 4:37 /usr/lib/systemd/systemd --user
1072 2206 0.0 0.0 260208 12356 ? Ss 2024 4:34 /usr/lib/systemd/systemd --user
1077 2207 0.0 0.0 262028 6692 ? Ss 2024 4:35 /usr/lib/systemd/systemd --user
1079 2209 0.0 0.0 262452 7180 ? Ss 2024 4:43 /usr/lib/systemd/systemd --user
1093 2210 0.0 0.0 263056 9808 ? Ss 2024 4:48 /usr/lib/systemd/systemd --user
1095 2221 0.0 0.0 265264 10000 ? Ss 2024 4:57 /usr/lib/systemd/systemd --user
1096 2222 0.0 0.0 263776 10300 ? Ss 2024 4:43 /usr/lib/systemd/systemd --user
1099 2224 0.0 0.0 263216 9912 ? Ss 2024 5:03 /usr/lib/systemd/systemd --user
1101 2225 0.0 0.0 262152 7276 ? Ss 2024 4:38 /usr/lib/systemd/systemd --user
1102 2226 0.0 0.0 263332 8828 ? Ss 2024 4:48 /usr/lib/systemd/systemd --user
1104 2227 0.0 0.0 263840 10340 ? Ss 2024 12:38 /usr/lib/systemd/systemd --user
1055 2366 0.0 0.0 260596 6828 ? Ss 2024 5:05 /usr/lib/systemd/systemd --user
(Забавный факт! Вы можете настроить ps для отображения UID (первый столбец) вместо имени пользователя, просто временно удалив все в /etc/passwd 😀 )
Таким образом, каждая система пользователя, которую я включил для всех пользователей, чтобы они могли иметь свои собственные услуги, пытается обрабатывать это устройство и терпит неудачу с отказом из-за прав доступа, потому что они, безусловно, не должны этого делать.
Я до сих пор не знаю почему.
ДОБАВЛЕНО 2: Да, это происходит с пользователем, который не является владельцем зашифрованного устройства, с systemctl list-units --user и некоторая правка; /home/tmp/mydev – это файл, из которого устанавливается устройство:
dev-disk-by\x2did-dm\x2dname\x2dmydev.device loaded active plugged /dev/disk/by-id/dm-name-mydev
dev-disk-by\x2dloop\x2dref-\x5cx2fhome\x5cx2ftmp\x5cx2fmydev.fs.device loaded active plugged /dev/disk/by-loop-ref/\x2fhome\x2ftmp\x2fmydev.fs
● dev-mapper-mydev.device loaded activating tentative /dev/mapper/mydev
home-tmp-mydev.mount loaded active mounted /home/tmp/mydev
● [email protected] not-found inactive dead [email protected]
Думаю, в этом замешан cryptmount.
ДОБАВЛЕНО 3: strace cryptmount не показывает ничего интересного, кроме вызова управления udev. Вероятно, это не udev, потому что после полного удаления всех правил udev временно я всё равно вижу:
● dev-mapper-mydev.device loaded activating tentative /dev/mapper/mydev
home-tmp-mydev.mount loaded active mounted /home/tmp/mydev
● [email protected] not-found inactive dead [email protected]
, и я подозреваю, что это первый элемент, который вызывает проблему.
Следовательно, возможно, это что-то глубоко в системе systemd? Пока нет четкого решения.
Ответ или решение
Для решения проблемы, заданной касательно сообщений systemd о попытках доступа к /dev/mapper/mydev на системе Fedora с усиленной политикой SELinux, следует рассмотреть несколько важных аспектов, которые позволят не только теоретически понять причину, но и практически решить возникшую задачу.
Теоретическая часть
В основе проблемы лежит способ, которым systemd обрабатывает устройства и монтировки. systemd отвечает за управление и наполнение каталогов dev/ при помощи служб, занимающихся их автоматической генерцией и обнаружением. Проблема в том, что systemd должен знать, какие устройства доступны и какие из них используются для монтировки. При этом, он может пытаться обращаться к устройствам, доступ к которым ограничен политиками SELinux или другими механизмами, такими как криптографическое шифрование.
-
Демон systemd и менеджмент устройств:
systemdуправляет устройствами с помощью системыudev, которая отвечает за поднятие и демонтаж устройств. Каждое новое устройство, подключенное к системе, распознаётся черезudev, и создается соответствующий блок в/dev.systemdиспользует это для поддержания устройств в актуальном состоянии и создания службных дескрипторов. -
Монтировки и модули:
- Монтировки устройств осуществляются через модули, такие как
cryptsetupилиcryptmount, которые отталкиваются от специфических правил конфигурации. Эти модули могут требовать создания маппера/dev/mapper/, отвечающего за конкретное устройство или том.
- Монтировки устройств осуществляются через модули, такие как
-
SELinux и права доступа:
- Политики SELinux в строгом режиме могут ограничивать доступные ресурсы и устройство может не соответствовать разрешённым политикам. Поскольку ваше устройство
/dev/mapper/mydevявляется шифрованным, может быть, что SELinux блокирует к нему доступ.
- Политики SELinux в строгом режиме могут ограничивать доступные ресурсы и устройство может не соответствовать разрешённым политикам. Поскольку ваше устройство
Пример процедуры
В вашей ситуации сообщения говорят о многократных неудачных попытках доступа к устройству, что может отрицательно сказаться на производительности и затрудняет администраторам понимание происходящего. Из-за ограничений, накладываемых SELinux, важно понять, как эти попытки влияют на безопасности и функциональность.
Наиболее вероятно, что одна из активных служб вашей системы пытается использовать устройство и сталкивается с отказом в доступе. Убедитесь, что у systemd есть только те монтировки, которые ему необходимы, и отключите ненужные. Для этого нужно:
- Проверьте системные юниты:
systemctl list-units --allи найдите те, которые могут взаимодействовать с вашим устройством. - Ознакомьтесь с пользовательскими юнитами:
systemctl list-units --userдля отдельных пользователей, чтобы понять, какие процессы взаимодействуют с устройством. - Используйте
udevadm monitorдля мониторинга событий, чтобы понять, какие действия инициирует или ожидаетsystemd.
Решение проблемы (Применение)
Применить ранее перечисленные знания можно несколькими способами:
-
Отладка и логгирование:
- Активировать подробный логгирование (verbose logging) в
systemd, чтобы лучше понимать, как система взаимодействует с устройством. Это можно сделать через изменение уровня логирования в конфигурацииsystemd.
- Активировать подробный логгирование (verbose logging) в
-
Отключение ненужных устройств:
- Отключите монтировки, если они не нужны, и установите строгие политики доступа на устройствах, используемых всеми юнитами
systemd, которые могут инициировать попытки взаимодействий с/dev/mapper/mydev.
- Отключите монтировки, если они не нужны, и установите строгие политики доступа на устройствах, используемых всеми юнитами
-
Настройка SELinux:
- Скорректируйте политики SELinux, чтобы избежать нежелательного доступа или устранить попытки доступа дополнительно не требуемые системой. Важным шагом будет применение
audit2allowдля создания и внедрения корректирующих политик, которые предотвращают несанкционированное чтение или запись.
- Скорректируйте политики SELinux, чтобы избежать нежелательного доступа или устранить попытки доступа дополнительно не требуемые системой. Важным шагом будет применение
-
Отключение user instance:
- Если проблема связана с пользовательскими инстанциями
systemd, например,systemd --user, временно отключите их выполнение, чтобы убедиться, что проблема связана именно с ними. Убедитесь, что только нужные процессы могут взаимодействовать с устройством.
- Если проблема связана с пользовательскими инстанциями
Таким образом, проблема многократных попыток доступа к /dev/mapper/mydev systemd может быть решена через комплексный подход, включающий настройку политики SELinux, корректировку конфигураций systemd и отключение ненужных пользовательских системных отображений. Это позволит минимизировать количество ложных срабатываний и предотвратить попытки незаконного доступа к защищённым данным.