Bug 158596 - df: `/var/named/chroot/proc': Permission denied
df: `/var/named/chroot/proc': Permission denied
Product: Fedora
Classification: Fedora
Component: util-linux (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2005-05-23 16:35 EDT by Thomas J. Baker
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-25 04:43:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)

  None (edit)
Description Thomas J. Baker 2005-05-23 16:35:31 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050512 Fedora/1.0.4-2 Firefox/1.0.4

Description of problem:
Not sure where this should be filed but when using a chroot bind, a normal user gets an error when doing a df:

wintermute> df
Filesystem           1K-blocks      Used Available Use% Mounted on
                      10157368   4854728   4778352  51% /
/dev/sdi2               101105     27318     68566  29% /boot
                       8256952   1972296   5865228  26% /usr/local
/dev/mapper/vgw0-web  14223724   1134172  12367020   9% /web
                      35252984  25883100   7579116  78% /home
                     384562228 292943732  72083856  81% /mirror
                     192263772  81304544 101192728  45% /temp
                     103212320  32554988  65414452  34% /raid
/dev/shm               2001592         0   2001592   0% /dev/shm
df: `/var/named/chroot/proc': Permission denied
/home/tjb             35252984  25883100   7579116  78% /net/home/rcc/tjb

When I first noticed this, I thought it was I copied my FC3 chroot directory over. But then I booted a rescue cd and removed the proc directory. Today I noticed the error is back. 

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

How reproducible:
Didn't try

Additional info:

I can track it down more if it's not easily reproducible.
Comment 1 Jason Vas Dias 2005-05-23 17:35:18 EDT
By default, the /var/named and /var/named/chroot partitions have mode:
0750 : drwxr-x--- and ownership root:named, ie. they are not readable 
/ searchable by "other" users that are not root and not in group named.
This is as it should be, to make BIND secure.

In order for named to correctly determine the correct number of CPUs,
the interface list, and other sysconf parameters, /proc needs to be
mounted under the root in which named runs, so if it is not mounted
under the chroot when named is to be started in a chroot, the
/etc/init.d/named script mounts it there ( bug 151852 ). 

'df' is being run under the non-root userid, who does not have
permission to read / search /var/named/chroot , and hence emits
the error message.

Now 'df' shouldn't really be telling you anything about mount points
that you do not have read/search permission to read / search ; 
however if you issue the "mount" command without any arguments
as a non-root user, it does list 
  "none on /var/named/chroot/proc type proc (rw)

This problem is a minor inconsistency between mount / df, 
but is NOT a bind bug.

If you feel strongly about it, please reopen this bug against 
coreutils (df should not emit the error message) or 
util-linux (mount should not report protected mount points to 
users who do not have permission to read or search them) .

Comment 2 Thomas J. Baker 2005-05-24 09:24:29 EDT
This is at least a regression as it didn't used to happen under fc3.
Comment 3 Jason Vas Dias 2005-05-24 10:23:43 EDT
Yes, df does emit the error message if run by a non-root user 
for 0750 protected mount points in FC3.
So non-root users are notified of mount points they are not 
meant to see through these error messages.
Comment 4 Tim Waugh 2005-05-24 10:46:26 EDT
Jason: what leads you to believe that df is behaving incorrectly here?  My
reading of the POSIX specification does not seem to say clearly one way or the
other about this.

If the issue is information leakage, mount is more responsible for it than df is
-- although /etc/mtab provides this information, as does /proc/mounts.

Resetting component.
Comment 5 Tim Waugh 2005-05-24 10:48:37 EDT
(Incidentally, this is *not* a change in behaviour for df since FC3.)
Comment 6 Thomas J. Baker 2005-05-24 11:00:06 EDT
I never saw this error before FC4. I've got a chrooted bind running on an fc3
system and don't see this error:

gile> ps -ef | grep named
named     3268     1  0 May10 ?        00:07:29 /usr/sbin/named -u named -t
tjb      18006 17948  0 10:57 pts/0    00:00:00 grep named
gile> df
Filesystem           1K-blocks      Used Available Use% Mounted on
                       8256952   6347956   1489568  81% /
/dev/sda1               101086     15856     80011  17% /boot
                       4128448     90460   3828276   3% /usr/local
                      21416524  10993240   9335388  55% /web
/dev/hda1             76920416  16857196  56155812  24% /backup
/dev/sdb1             17654736   1582164  15175748  10% /home
/dev/sdc1             35001508  16851616  16371900  51% /music
                      76923936  43183244  29833108  60% /mirror
none                    257240         0    257240   0% /dev/shm
/home/bc/tjb          17654736   1582164  15175748  10% /net/home/bc/tjb
Comment 7 Jason Vas Dias 2005-05-24 11:06:35 EDT
Yes, but as I said in Comment #3: this is NOT a regression 
(change in df or mount behaviour from FC3) - FC3's df/mount
behaves the same as FC4's df/mount.
In FC4, named mounts the proc filesystem under /var/named/chroot/proc;
in FC3, it does not (yet - the next FC3 bind release will also fix
bug 151852). 

The issue here is whether 
 A) df should be emitting an error message for mount points that the
    user has no  permission to read / search.
 B) mount should be reporting these protected mount points to users
    at all.

Comment 8 Karel Zak 2005-05-24 11:43:33 EDT
I'm confused.. I don't see any output from mount where is any problem. Please,
can you send me outputs from "mount" and "cat /proc/mounts".
Comment 9 Thomas J. Baker 2005-05-24 13:54:38 EDT
wintermute> mount
/dev/mapper/vgw0-root on / type ext3 (rw)
/dev/proc on /proc type proc (rw)
/dev/sys on /sys type sysfs (rw)
/dev/devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sdi2 on /boot type ext3 (rw)
/dev/mapper/vgw0-local on /usr/local type ext3 (rw)
/dev/mapper/vgw0-web on /web type ext3 (rw)
/dev/mapper/vgw1-home on /home type ext3 (rw)
/dev/mapper/vgw2-mirror on /mirror type ext3 (rw)
/dev/mapper/vgw3-temp on /temp type ext3 (rw)
/dev/mapper/vgraid-raid on /raid type ext3 (rw)
/dev/shm on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
none on /var/named/chroot/proc type proc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
automount(pid3344) on /net/nfs type autofs (rw,fd=4,pgrp=3344,minproto=2,maxproto=4)
automount(pid3409) on /net/home/rcc type autofs
automount(pid3471) on /net/rcc type autofs (rw,fd=4,pgrp=3471,minproto=2,maxproto=4)
automount(pid3541) on /net/home/ssc type autofs
automount(pid3615) on /net/app type autofs (rw,fd=4,pgrp=3615,minproto=2,maxproto=4)
automount(pid3696) on /net/music type autofs
automount(pid3781) on /net/home/sttg type autofs
nfsd on /proc/fs/nfsd type nfsd (rw)
/home/tjb on /net/home/rcc/tjb type none (rw,bind)
wintermute> cat /proc/mounts
rootfs / rootfs rw 0 0
/dev /dev tmpfs rw 0 0
/dev/root / ext3 rw 0 0
none /selinux selinuxfs rw 0 0
/proc /proc proc rw,nodiratime 0 0
/proc/bus/usb /proc/bus/usb usbfs rw 0 0
/sys /sys sysfs rw 0 0
/dev/devpts /dev/pts devpts rw 0 0
/dev/sdi2 /boot ext3 rw 0 0
/dev/vgw0/local /usr/local ext3 rw 0 0
/dev/vgw0/web /web ext3 rw 0 0
/dev/vgw1/home /home ext3 rw 0 0
/dev/vgw2/mirror /mirror ext3 rw 0 0
/dev/vgw3/temp /temp ext3 rw 0 0
/dev/vgraid/raid /raid ext3 rw 0 0
/dev/shm /dev/shm tmpfs rw 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
none /var/named/chroot/proc proc rw,nodiratime 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
automount(pid3344) /net/nfs autofs rw 0 0
automount(pid3409) /net/home/rcc autofs rw 0 0
automount(pid3471) /net/rcc autofs rw 0 0
automount(pid3541) /net/home/ssc autofs rw 0 0
automount(pid3615) /net/app autofs rw 0 0
automount(pid3696) /net/music autofs rw 0 0
automount(pid3781) /net/home/sttg autofs rw 0 0
nfsd /proc/fs/nfsd nfsd rw 0 0
/dev/vgw1/home /net/home/rcc/tjb ext3 rw 0 0
Comment 10 Karel Zak 2005-05-24 16:27:49 EDT
Thanks, but I don't see any problem. The directory "/var/named/chroot/proc" is
there. What do expect from the "mount" command?
Comment 11 Thomas J. Baker 2005-05-24 16:44:30 EDT
The bug is to do with df. See above comments.
Comment 14 Karel Zak 2005-05-25 04:43:04 EDT
>- mount should not tell the user about mount points they do not have
>  permission to know about 

 No way.

 They have permission to *know* about it. Maybe they not have permission
*access* the mount point. I think "access" and "know" are two different things.

> This is at least a regression as it didn't used to happen under fc3.

 My FC-3 box:

# mount -t proc none /root/aaa
# su - smith
$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda5             10080488   6484492   3083928  68% /
none                    258436         0    258436   0% /dev/shm
/dev/hda8             27040064   3024772  22641740  12% /home/work
/dev/hdb1             39563212  22248460  15305024  60% /home/store
df: `/root/aaa': Permission denied
$ rpm -q coreutils glibc util-linux

 I think you have different mount point permissions or users or so in FC3 and FC4.

 Please, don't open it anymore, else I will be more sarcastic next time :-)

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