Bug 162686 - /dev/root permissions should be 0640 (root.disk)
/dev/root permissions should be 0640 (root.disk)
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
11
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
David Lawrence
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-07 13:19 EDT by Gilbert E. Detillieux
Modified: 2013-04-21 12:18 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 13:13:39 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)

  None (edit)
Description Gilbert E. Detillieux 2005-07-07 13:19:51 EDT
Description of problem:
Not sure if udev is the right place for this, but it seems like the best fit.
With Fedora Core 3 and 4 (with 2.6 kernel and udev support), /dev/root comes up
with mode 0600, owner "root" and group "root".  This breaks backup routines,
like amanda, which rely on group-read permission for the "disk" group.  All the
other devices corresponding to mounted partitions seem to have the correct
permissions and group assignment, but not /dev/root, for some reason.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. set up the FC3 or FC4 host as an amanda client
2. set up your amanda server's disklist to include client host's "/" file system
3. run "amcheck" on amanda server
  
Actual results:
ERROR: fc4client: [could not access /dev/root (/): Permission denied]

Expected results:
The "amcheck" and "amdump" commands should work correctly, i.e. the amanda
client should have sufficient permissions to access /dev/root.

Additional info:
By manually running "chmod 640 /dev/root; chgrp disk /dev/root", I can fix the
problem temporarily.  However, these settings are lost on the next reboot.  I'm
not sure what the best way to fix this permanently would be, in keeping with the
udev way of doing things...
Comment 1 Matthew Saltzman 2005-07-16 19:23:49 EDT
This seems to be a broader issue than just /dev/root.  Other devices in the
"disk" group are also an issue.  

Amanda chokes because /dev/nst0 is 640, should be 660.  VMware raw disk access
fails because /dev/hda* is 640, should be 660.
Comment 2 Miguel Rosa 2005-08-23 06:52:55 EDT
I also have this problem. And I followed the rules at 
http://fedora.redhat.com/docs/udev/
by creating 
/etc/udev/permissions.d/51-new.permissions (same pugo has 50-udev.permissions)
containing

root:root:disk:0640

But after reboot nothing happens.
Comment 3 Bruce Bowler 2005-08-23 16:23:48 EDT
Creating a file called /etc/udev/rules.d/60-local.rules that contains the
following lines seems to solve the problem, at least as near as I can tell...

KERNEL=="hd[a-z]", BUS=="ide", SYSFS{removable}=="0",
PROGRAM=="/etc/udev/scripts/ide-media.sh %k", RESULT=="disk", GROUP=="disk",
MODE=="0660"
KERNEL=="hd[a-z]*", BUS=="ide", GROUP=="disk", MODE=="0660"

there's probably a more "robust" solution, but it works for me, so far...

Bruce
Comment 4 Harald Hoyer 2005-08-25 08:30:50 EDT
standard is 0640 ... see 

$ fgrep STORAGE /etc/makedev.d/00macros
=STORAGE  640 root disk

I will fix /dev/root, btw.
Comment 5 Matthew Saltzman 2005-08-25 09:02:39 EDT
...and yet in RHEL4 (something similar must have been in FC3):

# grep hd /etc/udev/permissions.d/50-udev.permissions
hd*:root:disk:0660

# grep st /etc/udev/permissions.d/50-udev.permissions
sndstat:root:root:0660
st*:root:disk:0660
nst*:root:disk:0660

Will fixing /dev/root solve amanda's problem if /dev/nst* (or whatever tape
device) isn't also changed?

Should I file a bug against amanda and ask for overrides in
/etc/udev/permissions for tape devices?
Comment 6 Harald Hoyer 2006-02-15 08:23:11 EST
should be fixed in current erratum
Comment 7 Gilbert E. Detillieux 2006-02-16 18:03:47 EST
I've updgraded to udev-071-0.FC4.2, and the problem I originally reported with
/dev/root still exists after a reboot.  This update adds the following line...

KERNEL=="root",                 GROUP="disk", MODE="0640"

... to /etc/udev/rules.d/50-udev.rules, which is something I had already tried
on my own.  Not sure why that doesn't work, though...

As for Matthew Saltzman's question about /dev/nst*, those devices would only be
used by amanda-server if you happen to be backing up to a tape drive.  This may
still be an issue for some, but my problem with /dev/root affects amanda-client
whenever you try to backup the root partition using the pathname "/" instead of
the actual device name.  (When you're backing up many client systems, each
having a potentially different physical device name for the root file system,
using the pathname "/" makes things much more manageable!)

As for where the bug should be filed, I think the /dev/root problem belongs in
udev, rather than amanda-client (since it could potentially affect other
software too).  The problem with /dev/nst* is also potentially not limited to
amanda-server - it's really a question of how those devices are likely to be
used, and by whom.
Comment 8 Harald Hoyer 2007-01-11 06:05:17 EST
$ find /sys/ -name root | wc -l
0

/dev/root is created with MAKEDEV
Comment 9 Harald Hoyer 2007-01-11 06:07:59 EST
oops, wrong.. hmm.. it's already there from initrd
Comment 10 Harald Hoyer 2007-01-11 06:08:37 EST
oops, wrong.. hmm.. it's already there from initrd
Comment 11 Christian Iseli 2007-01-19 19:11:29 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.
Comment 12 Matthew Saltzman 2007-01-20 14:33:26 EST
There are still /dev permission-related issues in FC6.

The tape devices are now 0660 owner root, group disk, which seems OK.

The disk devices are 0640 owner root, group disk, which is still an issue for
VMware raw disks.

/dev/root is still 0600, owner root, group root, which was the original
complaint.  Comments #4 and #6 promised a fix for this, but it doesn't appear to
have happened.  On the other hand, Amanda isn't complaining in my case.

Also, my scanner, /dev/sg0 is 0600, owner root, group root, which chokes xsane.
 Running xsane as normal user results in no devices found.  Running as root
results in a warning about running as root.
Comment 13 Gilbert E. Detillieux 2007-01-22 12:53:32 EST
I'm seeing exactly the same problem under both FC5 and FC6 as with previous
distributions. Permissions on /dev/root have not changed, as Matthew already
stated, and I still get the same errors from Amanda's "amcheck" program, due to
this permission problem. I've therefore updated the target version to fc6.
Comment 14 Ian Young 2007-05-26 06:02:57 EDT
Still appears to be present in Fedora 7 test 4.

True even after updating to most recent udev using yum (udev-106-4.fc7) and rebooting.
Comment 15 Anthony Thyssen 2008-02-28 19:30:13 EST
It is also a problem in FC8.

/dev/root has these permissions afetr reboot
   brw------- 1 root root 8, 2 2008-02-20 17:19 /dev/root
When it should have the permissions
   brw-r----- 1 root disk 8, 2 2008-02-20 17:19 /dev/root

However the udev permssion files have changed an no /dev/root rules
appear to exist any more, NOT that they worked in previous versions
of various linux distros.

Getting /dev/root is vital to ensuring successfull backup of machines

Comment 16 Bug Zapper 2008-05-14 07:57:43 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Gilbert E. Detillieux 2008-05-22 14:31:29 EDT
This is still a problem under Fedora 9...

brw------- 1 root root 8, 2 2008-05-22 13:23 /dev/root
Comment 18 Bug Zapper 2009-06-09 18:02:06 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 Bug Zapper 2009-07-14 13:13:39 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 20 Gilbert E. Detillieux 2009-07-23 12:35:08 EDT
This is still a problem under Fedora 11...

brw-------. 1 root root 8, 2 2009-07-23 11:23 /dev/root

Is anyone ever going to fix this simple bug, or should I just give up on attempting to reopen it for future Fedora releases?

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