Bug 160680

Summary: df command fails for non-root user when caching nameserver installed
Product: [Fedora] Fedora Reporter: John Horne <john.horne>
Component: coreutilsAssignee: Tim Waugh <twaugh>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: jvdias
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-06-22 13:22:01 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description John Horne 2005-06-16 12:31:45 EDT
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 13:18:39 EDT
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 06:38:04 EDT
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 10:50:37 EDT
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 11:53:48 EDT
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 12:26:43 EDT
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 12:27:40 EDT
I meant: "/var/named/ /var/named/chroot/ /var/named/chroot/proc".

Comment 7 John Horne 2005-06-17 12:41:52 EDT
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 13:22:01 EDT
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 11:12:24 EST
FWIW, this pstream patch:
  http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00273.html
looks like it might work around the problem.