Created attachment 417249 [details]
Modified version of the script "start_udev" to use umask 022
Description of problem:
For security reasons, umask is set to 027 on the system.
But when umask is set to 027 in "/etc/init.d/functions" (instead of the default of 022), hald fails to start the hald-addon-storage and therefore does not detect and auto-mount CDROM when inserted.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Edit and modify umask set in /etc/init.d/functions
2. Reboot the system
3. Insert a dvd or cdrom in the SATA DVD drive
No icon appears on the desktop, no Nautilus window appears browsing the files on the cdrom
Inserted cdrom is detected
When umask is set to 027, hald-addon-storage is not started.
Looking in hald verbose logs, it's not started because device is not known by hald:
hald-probe-storage: [D] probe-storage.c:153: Doing probe-storage for (bus usb) (drive_type cdrom) (udi=/org/freedesktop/Hal/devices/temp/137) (--only-check-for-fs==0)
hald-probe-storage: [D] probe-storage.c:162: Doing open ("", O_RDONLY | O_NONBLOCK)
hald-probe-storage: [E] probe-storage.c:165: Cannot open : No such file or directory
Similarily, with umask 027 hal-device does not list the cdrom SATA drive.
I think the failure comes down to this (using strace on hald at startup):
open("/dev/.udev/db", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 EACCES (Permission denied)
ie, if udev runs with umask 027, the rights on the directory /dev/.udev/db/ do not allow hald which runs as user "haldaemon" to access the data.
A possible fix is to force a umask of 022 for udev in the script "start_udev" after sourcing "/etc/init.d/functions"
I've moved the umask(022) call inside of udevd before it creates the /dev/.udev/ directory. So this should no longer be a problem in the upstream version.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Setting a 'umask' to a non-default value could cause some devices to not be readable by other processes. This update sets an explicit 'umask' for the udev daemon.
Same problem here. We've been working around it by running `udevtrigger' on boot, similar to the udev-post init script that has shown up in recent Fedoras.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.