Bug 160680

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 .  

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.

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.

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'.

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".

I meant: "/var/named/ /var/named/chroot/ /var/named/chroot/proc".

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.

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.

FWIW, this pstream patch:
  http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00273.html
looks like it might work around the problem.