[devel] /dev/cdrom

Пт Сен 27 14:54:31 MSK 2024

Интересное исследование.
И вы наверняка затронули актуальную для вас проблему.

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

27.09.2024 13:57, Paul Wolneykien пишет:
>    Всем привет.
>
>    Мне тут понадобилось разобраться, почему членство пользователя в
> группе "cdrom" не регламентирует доступ к оптическому приводу, как
> написано в документации к одному из наших дистрибутивов. Было ясно,
> что документация устарела, и нужно было во всём разобраться.
>
>    Начал я с проверки доступа к самому устройству /dev/cdrom. Именно тут
> начались главные сюрпризы. В самом деле! Если на вашем компьютере есть
> оптический привод, не поленитесь, скажите `ls -l /dev/sr0`. Я, честно
> говоря, ожидал увидеть там "brw-rw----+ 1 root cdrom". Но вместо этого
> там с большой долей вероятности окажется "brw-rw----+ 1 <ваше_имя>
> cdrom". Получается, что сколько не удаляй пользователя из группы
> "cdrom", а доступ к устройству у него всё равно будет, поскольку он
> owner данного файла устройства. Это, значит, во-первых, что если
> документация на систему говорит нам, что доступ к CD/DVD
> регламентируется членством в группе "cdrom", то это не правда. А
> во-вторых, что нужно выяснить, что же происходит.
>
>    Виновником смены ownership оказался модуль pam_console.so. Не готов
> сейчас оценить, насколько полезную работу он сейчас делает, возможно
> для некоторых устройств он всё ещё нужен, но на современных системах
> менять права доступа к /dev/cdrom таким образом явно избыточно (это,
> если мы вообще принимаем, что нужно менять ownership). Отключить данный
> эффект можно, отредактировав конфигурационный файл
> /etc/security/console.perms.d/50-default.perms (строки "cdrom" и
> "burner" заодно).
>
>    (Хорошо бы, конечно, не редактировать данный файл, а добавить
> соседний, переопределяющий его. Но я пока не придумал, как написать
> такой вариант, который бы удалял ненужные действия с cdrom,
> определённые в 50-defaults.perms.)
>
>    После редактирования 50-default.perms права на /dev/sr0 вроде бы
> приходят к ожидаемому виду "brw-rw----+ 1 root cdrom". Что будет,
> если теперь удалить пользователя из группы "cdrom" (usermod -r -G
> cdrom ...)? Я снова надеялся, что в доступе будет отказано. Однако, на
> современных наших системах, это предположение снова оказывается ложным.
> Натурально, права на /dev/sr0 только у root, а пользователь спокойно
> управляет лотком (команда eject) и даже может сделать образ диска
> (dd if=/dev/sr0 ...)! Хорошо ли это? То, что eject и т.д. работают,
> конечно, неплохо. Плохо то, что происходит это против ожиданий
> администратора (по крайней мере такого как я).
>
>    Исследование и чтение документации показало, что на этот раз за
> странностями стоит systemd-logind в компании с udev. Но как же он это
> делает, когда на устройстве написано "root cdrom"?! Ответ можно узнать,
> введя команду `getfacl /dev/sr0`. Она покажет, что на /dev/sr0 есть
> дополнительные права (файловый ACL).
>
>    Регулируется данный эффект файлом
> /usr/lib/udev/rules.d/70-uaccess.rules
> (там есть строчки про "optical drives"). Смысл в том, что если udev
> выставляет для данного устройства теги "uaccess" и "seat", то затем
> systemd-logind присоединяет устройство к рабочему месту пользователя
> (loginctl seat-status ...) и выполняет setfacl с выдачей персонального
> доступа (rw) к этому файлу.
>
>    Обращаю внимание, что документация про "uaccess" есть у RedHat и у
> Астры:
>
>    *https://wiki.astralinux.ru/pages/viewpage.action?pageId=217187404
>    *https://access.redhat.com/articles/3148751
>
>    Я пробовал искать слово "uaccess" по сайту docs.altlinux.org, но оно
> не нашлось. :(
>
>    Устранить данный эффект правильней всего созданием переопределяющего
> (override) файла в /etc/udev/rules.d/, обязательно с более поздним
> индексом, чем 70-*, например 99-uacess-override.rules и в нём удалить
> тег "uaccess" с устройства (в конце письма будет пример).
>
>    Дальше, последнее, что оставалось сделать, это решить вопрос с
> монтированием оптических дисков. Только этот момент во всей этой истории
> был для меня ожидаемым, потому что про udisks и polkit я кое-что знал.
> Решается добавлением "subject.isInGroup('cdrom')" в polkit с проверкой
> типа устройства.
>
>    Для чего я написал это длинное письмо? Во-первых, для информации, так
> как многое из вышеописанного не было для меня ожидаемым. А во-вторых,
> текущее поведение, сложившееся как мне кажется стихийно, требует
> осмысления и, возможно, модификации. Первое, что приходит на ум ---
> это отказ от pam_console.so в пользу systemd-logind (естественно,
> на системах с systemd). Но и пользователям SysV-init тоже стоит
> подумать, нужно ли вообще дарить пользователю все перечисленные в
> 50-default.perms устройства по случаю его входа в систему.
>
>    P. S. Обнаружил пакет polkit-rule-udisks2-mount, в котором
> игнорируется разделение на "mount" и "mount-other" принятое в
> udisks2. Если этот пакет установить, то пользователь получает
> доступ к устройствам, закреплённым за чужими рабочими местами.
> Мне кажется, что это ошибка.
> _______________________________________________
> Devel mailing list
> Devel на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
-- 

*Данил Шеин / Danil Shein*

dshein на altlinux.org
dshein на basealt.ru
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20240927/7134dffb/attachment-0001.html>