Bug 596774 - Using umask 027 prevents HAL daemon from reading udev data
Using umask 027 prevents HAL daemon from reading udev data
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: udev (Show other bugs)
5.5
All Linux
medium Severity medium
: rc
: ---
Assigned To: Harald Hoyer
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-27 09:47 EDT by Olivier Fourdan
Modified: 2013-03-03 21:49 EST (History)
6 users (show)

See Also:
Fixed In Version: udev-095-14.22.el5
Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-01-13 18:00:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Modified version of the script "start_udev" to use umask 022 (4.36 KB, text/plain)
2010-05-27 09:47 EDT, Olivier Fourdan
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0073 normal SHIPPED_LIVE udev bug fix and enhancement update 2011-01-12 12:22:05 EST

  None (edit)
Description Olivier Fourdan 2010-05-27 09:47:32 EDT
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):

udev-095-14.21.el5

How reproducible:

Always

Steps to Reproduce:
1. Edit and modify umask set in /etc/init.d/functions

   umask 027

2. Reboot the system
3. Insert a dvd or cdrom in the SATA DVD drive
  
Actual results:

No icon appears on the desktop, no Nautilus window appears browsing the files on the cdrom

Expected results:

Inserted cdrom is detected

Additional info:

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"
Comment 1 Kay Sievers 2010-05-30 17:50:42 EDT
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.
Comment 6 Martin Prpič 2010-12-06 09:13:55 EST
    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.
    
    New Contents:
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.
Comment 7 Joshua Roys 2011-01-06 15:12:28 EST
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.
Comment 9 errata-xmlrpc 2011-01-13 18:00:46 EST
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.

http://rhn.redhat.com/errata/RHBA-2011-0073.html

Note You need to log in before you can comment on or make changes to this bug.