Bug 596774 - Using umask 027 prevents HAL daemon from reading udev data
Summary: Using umask 027 prevents HAL daemon from reading udev data
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: udev   
(Show other bugs)
Version: 5.5
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Harald Hoyer
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-27 13:47 UTC by Olivier Fourdan
Modified: 2018-11-14 19:38 UTC (History)
6 users (show)

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 23:00:46 UTC
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 13:47 UTC, 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 17:22:05 UTC

Description Olivier Fourdan 2010-05-27 13:47:32 UTC
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 21:50:42 UTC
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 14:13:55 UTC
    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 20:12:28 UTC
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 23:00:46 UTC
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.