| Summary: | udev & permissions for cdroms | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Spider (RETIRED) <spider> |
| Component: | [OLD] Core system | Assignee: | Greg Kroah-Hartman (RETIRED) <gregkh> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | normal | CC: | confabulate, dberkholz, genstef |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Spider (RETIRED)
2004-10-08 00:14:25 UTC
I assume that http://forums.gentoo.org/viewtopic.php?p=1632264 is also caused by this bug? Rumor has it that the latest versions of udev fix this. Can you verify it? unable to boot my system with the latest version of udev, appears the device tarball got corrupted for some reason. Will try again as soon as my system is solid and stable. Nop, same results with last udev version. As far as I can see its theese rules that somehow conflict: cdrom*:root:cdrom:0660 dvd:root:cdrom:0660 rdvd:root:cdrom:0660 cdroms/*:root:cdrom:0660 hd*:root:disk:660 ide/*/*/*/*/*:root:disk:660 are permissions.d/ parsed in order? in such a case , its first set to cdrom, then set to disk.. (becuase yes, its a hd? ...) the same thing happens with /dev/sound/* devices. I'm using the latest stable udev. I don't see any rules in permissions.d/ that could conflict. Same here: crw------- 1 stefan tty 5, 1 24. Okt 23:31 /dev/console srwx------ 1 stefan root 0 24. Okt 23:31 /dev/gpmctl brw------- 1 stefan cdrom 22, 0 24. Okt 23:30 /dev/hdc crw------- 1 stefan root 29, 0 24. Okt 23:30 /dev/fb/0 lrwx------ 1 stefan users 64 25. Okt 00:05 /dev/fd/0 -> /dev/pts/2 l-wx------ 1 stefan users 64 25. Okt 00:05 /dev/fd/1 -> pipe:[30478] lrwx------ 1 stefan users 64 25. Okt 00:05 /dev/fd/2 -> /dev/pts/2 crw--w---- 1 stefan tty 136, 0 25. Okt 00:05 /dev/pts/0 crw--w---- 1 stefan tty 136, 1 25. Okt 00:05 /dev/pts/1 crw--w---- 1 stefan tty 136, 2 25. Okt 00:05 /dev/pts/2 crw------- 1 stefan audio 116, 0 24. Okt 23:31 /dev/snd/controlC0 crw------- 1 stefan audio 116, 24 24. Okt 23:31 /dev/snd/pcmC0D0c crw------- 1 stefan audio 116, 16 24. Okt 23:31 /dev/snd/pcmC0D0p crw------- 1 stefan audio 116, 25 24. Okt 23:31 /dev/snd/pcmC0D1c crw------- 1 stefan audio 116, 33 24. Okt 23:31 /dev/snd/timer latest ~x86 , udev-042 Try running "udevstart" after logging in, does that help? If so, its probably pam interfering (/etc/security/console.perms) > Try running "udevstart" after logging in, does that help?
> If so, its probably pam interfering (/etc/security/console.perms)
yes, it helps:
/home/stefan # ls /dev/hdc -la
brw------- 1 stefan root 22, 0 8. Nov 13:34 /dev/hdc
/home/stefan # udevstart
/home/stefan # ls /dev/hdc -la
brw-rw---- 1 root disk 22, 0 8. Nov 13:34 /dev/hdc
how do I get the right permissions on bootup now?
udev does set them correct on bootup. but when you login, pam steps in (see /etc/security/console.perms). should be fixed with latest pam releases. Maybe the pam problem is fixed, but the most important problem of the bug is not fixed. It is still present: lrwxrwxrwx 1 root root 3 10. Nov 20:38 /dev/cdrom -> hdc lrwxrwxrwx 1 root root 3 10. Nov 20:38 /dev/cdrw -> hdc lrwxrwxrwx 1 root root 3 10. Nov 20:38 /dev/dvd -> hdc brw-rw---- 1 root disk 22, 0 10. Nov 14:47 /dev/hdc /dev/cdroms: insgesamt 0 lrwxrwxrwx 1 root root 6 10. Nov 20:38 cdrom0 -> ../hdc This is exactly the result that we configured in permissions.d: cdrom*:root:cdrom:0660 dvd:root:cdrom:0660 rdvd:root:cdrom:0660 cdroms/*:root:cdrom:0660 hd*:root:disk:660 ide/*/*/*/*/*:root:disk:660 I do not know udev that good to get the ide-devfs.sh programm to decide whether to give cdrom permissions to hdc or not, but what I know for sure is, that it makes no sense to apply permissions to symlinks. Reopening I agree you can't apply permissions to symlinks. But how in the world are you supposed to determine the proper permission to give to hda, based on the fact that it's a cdrom or a disk? This is up to the user to configure on their own, udev can not currently handle this. If you have further questions about this, please bring them up on the linux-hotplug-devel mailing list, which is where the udev developers are. |