Re: [devel] Смена ownership в /dev/*

[Leonid Krivoshein <klark.devel@gmail.com>]

Привет!


On 9/27/24 15:18, Paul Wolneykien wrote:
> В Fri, 27 Sep 2024 14:54:31 +0300
> Danil Shein <dshein@basealt.ru> пишет:
>
>> Интересное исследование.
>> И вы наверняка затронули актуальную для вас проблему.
>>
>> Однако в моём поле зрения уже много лет нет ни одного компьютера с
>> оптическим приводом вообще.
>    По мне, так сам принцип временной (!) смены ownership чего-то в
> /dev/* выглядит как ужос-ужос. CD --- это просто иллюстрация. Вероятно,
> нужно сменить тему письма.

Аналогичные недоумения пользователей относительно владельца, группы и 
прав доступа в пакете alterator-ports-access. Просто, кому какое дело в 
современном десктопном дистрибутиве с polkit+udisks2, какие там права у 
устройств в /dev, эта парочка обеспечит любые права независимо от прав 
пользователя на устройство.

Плюс: опции пользовательского монтирования в /etc/fstab остались за 
кадром исследования.


>> Они как бы вымерли лет 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
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
WBR, Leonid Krivoshein.