Bug 383531 - Anaconda doesn't set correct permissions on /dev/null
Anaconda doesn't set correct permissions on /dev/null
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
5.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Alexander Todorov
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-14 17:03 EST by Chris Adams
Modified: 2010-10-22 16:27 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 05:54:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Remove the umask temporarily so that devices are created with correct permissions. (905 bytes, patch)
2009-03-23 22:55 EDT, Wade Mealing
no flags Details | Diff

  None (edit)
Description Chris Adams 2007-11-14 17:03:56 EST
I've got a kickstar that runs some %post things as users to make it easy to get
the correct permissions and such (using "runuser -c command user").  This breaks
when it tries to access /dev/null, because /mnt/sysimage/dev/null is mode 644
instead of 666.

Minor thing (I'm working around it with a chmod in my kickstart), but there may
be other dev nodes with wrong permissions that could cause problems (if an RPM
%post tried to write to /dev/null as a user it would fail for example).
Comment 1 John Brier 2007-11-19 14:41:17 EST
I used a RHEL 5.0 install and had the same issue. In my post I setup this:
%post
df -h /dev/null >> /root/null_test.txt
ls -l /dev/null >> /root/null_test.txt
/sbin/start_udev
ls -l /dev/null >> /root/null_test.txt

which gives me this:
# cat null_test.txt 
Filesystem            Size  Used Avail Use% Mounted on
-                     506M     0  506M   0% /dev
crw-r--r-- 1 root root 1, 3 Nov 16 12:19 /dev/null
crw-rw-rw- 1 root root 1, 3 Nov 16 17:37 /dev/null

So another work around aside from chmod is to use /sbin/start_udev
Comment 2 Joel Andres Granados 2008-06-12 08:10:14 EDT
Is this still an issue in 52?
Comment 3 Chris Adams 2008-06-13 10:53:24 EDT
Yes, this still appears to be a problem with RHEL 5.2.
Comment 4 Jeff Bastian 2008-07-14 21:24:48 EDT
I've also confirmed this is still a problem in RHEL 5.2.

RHEL 4.6 and Fedora 9 have /dev/null and /mnt/sysimage/dev/null correctly set to
666.
Comment 5 Jeff Bastian 2008-07-14 22:25:03 EDT
Actually, there are a number of devices in RHEL 5.2 that have the wrong
permissions.  According to loader2/devices.h, these devices should have group
and/or other writable permissions:
    {"null", CHARDEV, 1, 3, 0666, "root", "root"},
    {"zero", CHARDEV, 1, 5, 0666, "root", "root"},
    {"ptmx", CHARDEV, 5, 2, 0666, "root", "root"},
    {"agpgart", CHARDEV, 10, 175, 0664, "root", "root"},
    {"input/mice", CHARDEV, 13, 63, 0664, "root", "root"},

However, they don't:
    crw-r--r-- 1 root 0  10, 175 Jul 14 22:03 agpgart
    crw-r--r-- 1 root 0  13,  63 Jul 14 22:03 input/mice
    crw-r--r-- 1 root 0   1,   3 Jul 14 22:03 null
    crw-r--r-- 1 root 0   5,   2 Jul 14 22:03 ptmx
    crw-r--r-- 1 root 0   5,   0 Jul 14 22:03 tty
    crw-r--r-- 1 root 0   1,   5 Jul 14 22:03 zero

I suspect this is because of line 586 of init.c (in anaconda-11.1.2.114):
    umask(022);

This line also exists in anaconda for RHEL 4.x and Fedora 9, however, RHEL 4.x
had it's /dev/* entries pre-created in the initrd.img, and F9 is more integrated
with udev, so the permissions are correct in those releases.

The mknod(2) man page indicates:
       The permissions are modified by the process’s umask in the  usual  way:
       the permissions of the created node are (mode & ~umask).
Comment 6 Chris Adams 2009-02-03 22:25:51 EST
This is still a problem with RHEL 5.3.
Comment 7 Wade Mealing 2009-03-23 22:40:27 EDT
My first stab at fixing the bug. I had originally thought that a package may have created the files in /mnt/sysimage/dev , although it seems to be a bind style mount at anaconda runtime.

This kind of bug only seems to affect RHEL 5, Fedora 10 does not seem to be affected.
Comment 8 Wade Mealing 2009-03-23 22:55:42 EDT
Created attachment 336417 [details]
Remove the umask temporarily so that devices are created with correct permissions.

Initial tests show that the patch above allows device nodes to be made with the octal permissions as per the header file.

I completed a minimal installation as a test, things seemed to work with no adverse side effects.
Comment 11 RHEL Product and Program Management 2009-04-22 10:10:08 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 13 Chris Lumens 2009-04-29 13:21:09 EDT
This should be fixed in anaconda-11.1.2.171-1.  Thanks for the patch.
Comment 16 Alexander Todorov 2009-05-08 09:34:09 EDT
verified with anaconda-11.1.2.172-1 that devices have the same permissions as in loader2/devices.h (see comment #5)
Comment 18 errata-xmlrpc 2009-09-02 05:54:11 EDT
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-2009-1306.html

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