[devel] /dev/cdrom

[devel] /dev/cdrom

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

Re: [devel] Смена ownership в /dev/* (was: /dev/cdrom)

[Paul Wolneykien]

В Fri, 27 Sep 2024 14:54:31 +0300
Danil Shein <dshein@basealt.ru> пишет:

> Интересное исследование.
> И вы наверняка затронули актуальную для вас проблему.
> 
> Однако в моём поле зрения уже много лет нет ни одного компьютера с 
> оптическим приводом вообще.

  По мне, так сам принцип временной (!) смены ownership чего-то в
/dev/* выглядит как ужос-ужос. CD --- это просто иллюстрация. Вероятно,
нужно сменить тему письма.

> Они как бы вымерли лет 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  

Re: [devel] /dev/cdrom

[Sergey V Turchin]

On Friday, 27 September 2024 14:54:31 MSK Danil Shein wrote:
> Интересное исследование.
> И вы наверняка затронули актуальную для вас проблему.
> 
> Однако в моём поле зрения уже много лет нет ни одного компьютера с
> оптическим приводом вообще.
> Они как бы вымерли лет 5 назад.
> Как артефакт имеется в наличии внешний USB привод, но и он давно пылится
> без дела.
Это хорошо, что у нас в стране флоповоды наконец-то вымерли. Теперь ещё DVD 
столько же ждать.

[...]

-- 
Regards, Sergey.

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

[Leonid Krivoshein]

Привет!


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.

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

[Paul Wolneykien]

В Fri, 27 Sep 2024 22:52:29 +0300
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  
> 

Re: [devel] TAG="uaccess": possible BUG in systemd-udevd (was: /dev/cdrom)

[Paul Wolneykien]

В Fri, 27 Sep 2024 13:57:31 +0300
Paul Wolneykien <manowar@altlinux.org> пишет:

> Обращаю внимание, что документация про "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" с устройства (в конце письма будет пример).

  Обнаружил, что рецепт удаления тега "uaccess" через TAG-="uaccess"
ведёт себя нестабильно. Если систему перезагрузить штатно, то
":uaccess:" не попадает в CURRENT_TAGS и setfacl /dev/sr0 тоже не
выполняется (ACL на устройство не добавляется). Однако, если вручную
вызвать:

    udevadm trigger /dev/sr0

то, хотя ":uaccess:" также не попадает в CURRENT_TAGS (но теги идут в
ином порядке), однако setfacl /dev/sr0 в этом случае выполняется (!),
добавляя ACL. Мне это очень напоминает race. Это можно резюмировать
так:

  1. наблюдается не одинаковый эффект от работы правил udev при
загрузке системы и при trigger (порядок тегов изменяется);

  2. несмотря на видимое отсутствие ":uaccess:" в CURRENT_TAGS,
ACL на устройство выдаётся пользователю, совершившему вход в вистему
(setfacl вызывается).

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

[Leonid Krivoshein]

On 9/28/24 00:57, Paul Wolneykien wrote:
> В Fri, 27 Sep 2024 22:52:29 +0300
> 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, эта парочка обеспечит любые права независимо от прав
>> пользователя на устройство.
>    Ну, не совсем: сделать образ диска и даже прожечь диск можно (и
> нужно?) без монтирования.

К недоумению приводит как раз наоборот -- неудачная попытка понизить 
права. Например, установка прав 0400 на устройство USB со вставленной 
флешкой в этом интерфейсе "неожиданно" не ограничивает права записи на 
эту флешку.

Возвращаясь к теме сабжа: если бы не правила udev, все устройства 
принадлежали бы root и имели некое дефолтное значение прав доступа. Но 
что даёт их изменение при куче способов обойти эти ограничения.

>> Плюс: опции пользовательского монтирования в /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
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
WBR, Leonid Krivoshein.