наблюдал на свежем Desktop 4.0

(In reply to comment #0)
> broken permissions on cdrws:
> pam0_console полагается на какое-то устаревшее поведение udev.

Конфигурация pam0_console последний раз правилась, когда udev ещё не было.
Надо её привести в соответствие с udev'ом.

> pam0_console-0.99.6.3-alt2
> Имеем два пишущих привода:
> /dev/hdd:
>  Model=SONY DVD RW AW-G170A, FwRev=1.71, SerialNo=
> 
> /dev/hdc:
>  Model=TSSTcorp CDW/DVD SH-M522C, FwRev=TS03, SerialNo=
> 
> оба пишущие.
> 
> имеем симлинки: (автосозданы)
> l /dev/cd* /dev/dvd*
> lrwxrwxrwx 1 root root 3 Sep 17  2007 /dev/cdrom -> hdc
> lrwxrwxrwx 1 root root 3 Sep 17  2007 /dev/dvd -> hdc
> 
> pam0_console пихает их в группу cdrom:
> l /dev/hd[cd]
> brw-r----- 1 dad  cdrom 22,  0 Sep 17  2007 /dev/hdc
> brw-r----- 1 root cdrom 22, 64 Sep 17  2007 /dev/hdd
> при чем, интересно, пользователю дает только 1 :(
> Это баг.

Что, по вашему, здесь неправильно?

> А для исправления, почему бы 
> не поправить в /etc/security/console.perms
> -<console>  0640 <cdrom>      0640 root.cdrom
> +<console>  0660 <cdrom>      0660 root.cdrom
> 
> Ведь честному сидирому запись не повредит,
> а не частному (cd/dvd writer) - нужна позарез!

Зачем группе cdrom давать право на запись в устройство?

(In reply to comment #2)
> (In reply to comment #0)
> > broken permissions on cdrws:
> > pam0_console полагается на какое-то устаревшее поведение udev.
> 
> Конфигурация pam0_console последний раз правилась, когда udev ещё не было.
> Надо её привести в соответствие с udev'ом.

Сейчас я готовлю обновление pam'а, pam-redhat-0.80-alt-pam_console-config.patch
опять полностью отъехал, так что самое время синхронизироваться, если это
необходимо.

Нет реакции - нет проблемы.

У led@ были некоторые соображения, помнится...

(In reply to comment #5)
> У led@ были некоторые соображения, помнится...

Это когда до офиса доберусь, посмотрю что я там в udev-правилах правил.
AFAIK что-то на предмет того, чтобы DVD-ROM всегда выставлялся в 640 и группу 
cdrom, а DVD-RW - в 660 и группу cdwriter

ldv> Нет реакции - нет проблемы.

Гм. у меня был завал + проблемы с почтовым ящиком, 
поэтому и не смог среагировать вовремя.

А если я умру или тяжело заболею, разве это повод, чтобы закрывать  баг?
Как математик и платоник, я верю, что баг -
права 644 на cdrw/dvdrw вместо 664 - 
таки обьективно существует :)

так что, пусть будет REOPEN, все-таки вдруг кто починит ...

(In reply to comment #2)


> > pam0_console пихает их в группу cdrom:
> > l /dev/hd[cd]
> > brw-r----- 1 dad  cdrom 22,  0 Sep 17  2007 /dev/hdc
> > brw-r----- 1 root cdrom 22, 64 Sep 17  2007 /dev/hdd
> > при чем, интересно, пользователю дает только 1 :(
> > Это баг.
> 
> Что, по вашему, здесь неправильно?
> 
> > А для исправления, почему бы 
> > не поправить в /etc/security/console.perms
> > -<console>  0640 <cdrom>      0640 root.cdrom
> > +<console>  0660 <cdrom>      0660 root.cdrom
> > 
> > Ведь честному сидирому запись не повредит,
> > а не частному (cd/dvd writer) - нужна позарез!
> 
> Зачем группе cdrom давать право на запись в устройство?
 
В системе может быть залогинено больше одного пользователя. Владельцем устройства становится только один. Остальные диски писать не могут.

Я тоже натыкался на эту граблю, сейчас посмотрел- с нынешним pam0_console, udev и
ядром 2.6.24 бага вроде как рассосалась, но с ядром 2.6.18- присутствует.
А вот когда удалил из /etc/security/console.perms.d/50-default.perms строчки,
содержащие <cdrom> и <burner>, бага пропала и на ядре 2.6.18.

Пакет pam0_console и весь механизм console.perms давно удалены из Сизифа (pam_console.so и /etc/security/console.perms не поставляет ни один пакет). Права на устройства для консольного пользователя теперь выдаёт systemd-logind через udev uaccess (ACL), а IDE-имён /dev/hdX не существует со времён libata. Неактуально.