ALT Linux Team development discussions
 help / color / mirror / Atom feed
* [devel] /dev/cdrom
@ 2024-09-27 10:57 Paul Wolneykien
    2024-09-27 22:34 ` [devel] TAG="uaccess": possible BUG in systemd-udevd (was: /dev/cdrom) Paul Wolneykien
  0 siblings, 2 replies; 7+ messages in thread
From: Paul Wolneykien @ 2024-09-27 10:57 UTC (permalink / raw)
  To: ALT Linux Team development discussions


  Всем привет.

  Мне тут понадобилось разобраться, почему членство пользователя в
группе "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. Если этот пакет установить, то пользователь получает
доступ к устройствам, закреплённым за чужими рабочими местами.
Мне кажется, что это ошибка.


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2024-09-27 22:46 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-09-27 10:57 [devel] /dev/cdrom Paul Wolneykien
2024-09-27 12:18   ` [devel] Смена ownership в /dev/* (was: /dev/cdrom) Paul Wolneykien
2024-09-27 19:52     ` [devel] Смена ownership в /dev/* Leonid Krivoshein
2024-09-27 21:57       ` Paul Wolneykien
2024-09-27 22:46         ` Leonid Krivoshein
2024-09-27 12:19   ` [devel] /dev/cdrom Sergey V Turchin
2024-09-27 22:34 ` [devel] TAG="uaccess": possible BUG in systemd-udevd (was: /dev/cdrom) Paul Wolneykien

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git