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