Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 160680 - df command fails for non-root user when caching nameserver installed
Summary: df command fails for non-root user when caching nameserver installed
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: 4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-16 16:31 UTC by John Horne
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-06-22 17:22:01 UTC


Attachments (Terms of Use)

Description John Horne 2005-06-16 16:31:45 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
Performed initial install of FC4. Included caching-nameserver. AT system boot caching nameserver is started up. As a non-root user the 'df -k' command gives an error:

==============================================================
df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/md2               8955432   6227920   2265256  74% /
/dev/md0                100890     15381     80300  17% /boot
/dev/shm                257312         0    257312   0% /dev/shm
df: `/var/named/chroot/proc': Permission denied
==============================================================

It seems that /etc/mtab has an entry for '/var/named/chroot/proc':

   none /var/named/chroot/proc proc rw 0 0

but an ordinary user has no permission to that area. 'rpm -qf' shows the directory is from the bind-chroot package.


Version-Release number of selected component (if applicable):
caching-nameserver-7.3-3 and bind-chroot-9.3.1-4 and coreutils-5.2.1-48

How reproducible:
Always

Steps to Reproduce:
1.Install FC4 caching nameserver.
2.As non-root user issue 'df -k' command.
3.
  

Actual Results:  A permission denied error appears as shown above.

Expected Results:  Nothing. All the disks etc should be shown with their amount of space available, in use etc.

Additional info:

Comment 1 Jason Vas Dias 2005-06-16 17:18:39 UTC
There is definitely some weird behaviour from coreutils' "df" going on here.
With named running from a chroot (bind-chroot package installed, 
"service named start" run):

If, as root, you do:
 # chmod o+rx /var/named /var/named/chroot /var/named/chroot/proc

And then, as a non-root user:
 $ df

df completes normally without any errors, but 
DOES NOT DISPLAY ANYTHING about /proc mounts.

But if you leave the /var/named{/,/chroot,/chroot/proc} directories with
their default permissions as on clean install: 
  # chmod o-rx /var/named{/,/chroot,/chroot/proc}

And then as a non-root user do:
  $ df

df emits these error messages and EXITS WITH '1' exit status:
  df: `/proc/sys/fs/binfmt_misc': permission denied
  df: `/var/named/chroot/proc:' permission denied

There are several df problems here:

1. If df does not display anything about procfs mounts to a non-root user
   when the permission of /var/named/chroot/proc allows read/search by
   "other", then it should not display anything about procfs mounts
   if this permission is not granted.

2. When the permission of /var/named/chroot/proc does not allow read/search
   by other, why does df complain about lack of permissions for
   /proc/sys/fs/binfmt_misc  ?

3. df should not be exiting with a failure exit status if it does not 
   have read+search permission for a procfs mount point, as if it had
   such permission, it would report nothing about procfs mount points.

The temporary workaround for this bug is to do:
   # chmod o+rx /var/named/{/,chroot/,chroot/proc}
which somewhat reduces the security afforded by the bind-chroot 
environment.

Note that the extra bind-chroot security is made redundant by the named SELinux
security policy: if you have SELinux enabled, then you should do 
  # rpm -e bind-chroot
and the named SELinux policy would provide more security than the bind-chroot
environment did, and this problem would not occur.

But I think the df problems above should be fixed .  

Comment 2 John Horne 2005-06-17 10:38:04 UTC
Two points here:

1) I get no errors about binfmt_misc, only the /var/named/chroot entry. However!
Having used your workaround, 'df' worked fine. Setting the
/var/named{/,chroot/,chroot/proc} permissions back again to their original
values, I now get an error:

  df -k
  Filesystem           1K-blocks      Used Available Use% Mounted on
  /dev/md2               8955432   6239508   2253668  74% /
  /dev/md0                100890     15382     80299  17% /boot
  /dev/shm                257312         0    257312   0% /dev/shm
  df: `/proc/sys/fs/binfmt_misc': Permission denied
  df: `/var/named/chroot/proc': Permission denied

The /var/named/chroot/proc is a link to /proc so should be set to mode 555 (I
think!). The problem is /var/named and /var/named/chroot, not the
/var/named/chroot/proc (or /proc) directories.

2) An interesting point about not needing bind-chroot because of SElinux. It
would seem best (for us) to remove the bind-chroot if SElinux provides the same
security.



Comment 3 Jason Vas Dias 2005-06-17 14:50:37 UTC
The /var/named/chroot/proc is not a link, or should not be - nothing in the
BIND scripts makes it into a link - it cannot be a symbolic link as it would 
not resolve under a chroot, nor can it be a hardlink as /var is often on a
different partition to / - the proc filesystem must be mounted there.

BIND can get some sysconf(3) parameters and interface lists wrong if the proc fs
is not mounted under the /proc in the root in which it runs.

Yes, having SELinux Enabled and Enforcing is more secure than the bind-chroot 
environment .

Just to clarify, here are the anomalous effects of different modes on df(1)
behavior:

[ root # ] ls -ld /var/named{/,/chroot{/,/proc}}
drwxr-x---    3 root named 1024 May 25 18:54 /var/named/
drwxr-x---    5 root named 1024 May 25 18:55 /var/named/chroot/
dr-xr-xr-x  114 root root     0 Jun 17 10:13 /var/named/chroot/proc

[ user $ ] df -kl
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda8               507588    358708    122674  75% /
/dev/hda1               128357     10544    111186   9% /boot
none                    257380         0    257380   0% /dev/shm
/dev/hda11             9422000   5406124   3537256  61% /home
/dev/hda6              2063160     34496   1923860   2% /tmp
/dev/hda9              8256888   5753492   2083972  74% /usr
/dev/hda10             4128320   2629228   1289332  68% /usr/src
/dev/hda7               507588    297221    184161  62% /var
df: `/var/named/chroot/proc': Permission denied
[ user $ ] echo $?
1

[ root # ] chmod go+rx /var/named{/,/chroot{/,/proc}}
[ root # ] ls -ld /var/named{/,/chroot{/,/proc}}
drwxr-xr-x    3 root named 1024 May 25 18:54 /var/named/
drwxr-xr-x    5 root named 1024 May 25 18:55 /var/named/chroot/
dr-xr-xr-x  115 root root     0 Jun 17 10:13 /var/named/chroot/proc

[ user $ ] df -kl
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda8               507588    358708    122674  75% /
/dev/hda1               128357     10544    111186   9% /boot
none                    257380         0    257380   0% /dev/shm
/dev/hda11             9422000   5406124   3537256  61% /home
/dev/hda6              2063160     34496   1923860   2% /tmp
/dev/hda9              8256888   5753492   2083972  74% /usr
/dev/hda10             4128320   2629228   1289332  68% /usr/src
/dev/hda7               507588    297227    184155  62% /var
[ user $ ] echo $?
0

[ root # ] chmod go-rx /var/named{/,/chroot{/,/proc}}
[ root # ] ls -l /var/named{/,/chroot{/,/proc}}
drwx------    3 root named 1024 May 25 18:54 /var/named/
drwx------    5 root named 1024 May 25 18:55 /var/named/chroot/
dr-x------  114 root root     0 Jun 17 10:13 /var/named/chroot/proc

[ user $ ] df -kl
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda8               507588    358708    122674  75% /
/dev/hda1               128357     10544    111186   9% /boot
none                    257380         0    257380   0% /dev/shm
/dev/hda11             9422000   5406124   3537256  61% /home
/dev/hda6              2063160     34496   1923860   2% /tmp
/dev/hda9              8256888   5753492   2083972  74% /usr
/dev/hda10             4128320   2629228   1289332  68% /usr/src
/dev/hda7               507588    297227    184155  62% /var
df: `/proc/sys/fs/binfmt_misc': Permission denied
df: `/var/named/chroot/proc': Permission denied
[ user $ ] echo $?
1

df(1) should really not be returning failure if it does not have
permission to find out about a mount-point that it would display
no information about if it had such permission.

Also the effect of complaining about /proc/sys/fs/binfmt_misc if
df has no permission for /var/named/chroot/proc is very weird.




Comment 4 John Horne 2005-06-17 15:53:48 UTC
I am a bit confused about what the /var/named/chroot/proc is then. In my case I
can see:

   [root@jhorne proc]# ls -ldi /proc  /var/named/chroot/proc
   1 dr-xr-xr-x  161 root root 0 Jun 17 11:13 /proc
   1 dr-xr-xr-x  161 root root 0 Jun 17 11:13 /var/named/chroot/proc

which to me makes them look exactly the same. /var is on the same partition as '/'.

I thought the problem with binfmt_misc was caused by the fact that you ran
'chmod go-rx /var/named{/,/chroot{/,/proc}}'. As such I suspect that '/proc' on
your system has now been changed from its usual 555 mode. Hence binfmt_misc
cannot be read either so causes a problem for 'df'.



Comment 5 Jason Vas Dias 2005-06-17 16:26:43 UTC
The /proc and /var/named/chroot/proc are mount points to the same filesystem,
which is why they look the same - /var/named/chroot/proc is NOT a link to /proc.
The mode of my /proc mountpoint was never changed from 555, because 
/var/named{/,/chroot{/,/proc}} expands to 
"/var/named/ /var/named/chroot/ /var/named/proc".


Comment 6 Jason Vas Dias 2005-06-17 16:27:40 UTC
I meant: "/var/named/ /var/named/chroot/ /var/named/chroot/proc".



Comment 7 John Horne 2005-06-17 16:41:52 UTC
Yes, but:

   [root@jhorne chroot]# ls -ldi /proc /var/named/chroot/proc
   1 dr-xr-xr-x  162 root root 0 Jun 17 11:13 /proc
   1 dr-xr-xr-x  162 root root 0 Jun 17 11:13 /var/named/chroot/proc

   chmod go-rx /var/named{/,/chroot{/,/proc}}

   [root@jhorne chroot]# ls -ldi /proc /var/named/chroot/proc
   1 dr-x------  162 root root 0 Jun 17 11:13 /proc
   1 dr-x------  162 root root 0 Jun 17 11:13 /var/named/chroot/proc

   chmod go+rx /var/named{/,/chroot{/,/proc}}

   [root@jhorne chroot]# ls -ldi /proc /var/named/chroot/proc
   1 dr-xr-xr-x  162 root root 0 Jun 17 11:13 /proc
   1 dr-xr-xr-x  162 root root 0 Jun 17 11:13 /var/named/chroot/proc

So the permissions on /proc have changed, and df gives an error about binfmt_misc.


Comment 8 Tim Waugh 2005-06-22 17:22:01 UTC
df is not in error here.

Filesystem statistics are omitted for filesystems where fsu_blocks==0, and this
includes procfs.  As root, you can run 'df -ah' and see information on the
'hidden' filesystem.

The catch is that it only knows that it can omit that filesystem *if* it can
statvfs it and find out what fsu_blocks is.  Otherwise it may be any filesystem
type.

Comment 9 Tim Waugh 2005-12-02 16:12:24 UTC
FWIW, this pstream patch:
  http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00273.html
looks like it might work around the problem.


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