Bug 31375

Summary: "cd .." at mount-point uses perms of dir under mount
Product: Base System Reporter: Phil Pennock <pdp>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.4-STABLE   
Hardware: Any   
OS: Any   

Description Phil Pennock 2001-10-19 16:20:00 UTC 
It appears that when determining where ".." is, in a directory which is
a mount-point, the file-permissions of the underlying directory are used,
rather than the permissions of the mounted directory.  See below for
evidence backing this analysis.

Found because it breaks /etc/periodic/weekly/310.locate

Note that the practice of "chmod 0 /a/mountpoint" is not unusual.

Workaround: change permissions of mountpoints

Fix: 

Unknown
How-To-Repeat: # mkdir /d/mounthere
# touch /d/mounthere/NOTHING_MOUNTED_HERE
# chmod 0 /d/mounthere
[ have a relevant filesystem in /etc/fstab, or choose one ]
# mount /d/mounthere
# su -m nobody
$ cd /d/mounthere
$ pwd
/d/mounthere
$ ls -ld .
drwxr-xr-x  2 root  wheel  512 Oct 18 20:42 .
$ cd ..
cd: can't cd to ..
$ <control-D>
# umount /d/mounthere
# chmod 555 /d/mounthere
# mount /d/mounthere
# su -m nobody
$ cd /d/mounthere
$ cd ..
$ pwd
/d
$
Comment 1 des 2001-10-20 12:33:59 UTC 
pdp@nl.demon.net writes:
> $ cd /d/mounthere
> $ pwd
> /d/mounthere
> $ ls -ld .
> drwxr-xr-x  2 root  wheel  512 Oct 18 20:42 .
> $ cd ..
> cd: can't cd to ..

This is not a bug.  It happens because the fs you mounted on top of
/d/mounthere doesn't know shit about the mountpoint or its parent, and
has no way of returning a vnode to the mountpoint's parent, so (as a
special case) you have to look up .. in the covered node instead of in
the covering one.  The error here is in you removing read and search
permission from the mountpoint.

(another reason why .. must be special-cased is that it is meaningless
for the root directory, and the one in the root directory of a chroot
or jail must be hidden from some processes but not others - it
wouldn't do to rely on the individual vfs to do this)

> Workaround: change permissions of mountpoints

Fix, not workaround.  The permissions of the covered node are *not*
irrelevant; in some cases (like msdosfs) they even control the
behaviour of the mounted filesystem.

DES
-- 
Dag-Erling Smorgrav - des@ofug.org
Comment 2 Dag-Erling Smørgrav freebsd_committer freebsd_triage 2001-10-20 12:34:20 UTC 
State Changed
From-To: open->closed

Not a bug.