bug related to mounted file systems and ..

[utzoo!decvax!ucbvax!unix-wizards]

>From decvax!shannon at Berkeley Tue Sep 29 15:13:39 1981

This started as a bug for 4bsd-bugs, but since it has wider
applicability I thought I'd send it to unix-wizards in case
anyone else has seen it before and/or has a solution.

There is a very subtle bug in the handling of mounted file
systems.  The bug occurs when trying to reference ".." from
the root of a mounted file system (such as trying to do a
"cd .." or even just a pwd).  Although the manual says that
a file system can only be mounted on a directory (unless the
root of the mounted file system is a regular file), this is
not checked anywhere.  If a file system is mounted on a regular
file and a "cd .." attempted from the root of the mounted
file system, you get the error message "..: Not a directory".
The following sequence reproduces the problem:

	cp /dev/null /m
	mount /dev/hp0g /m	(for instance)
	cd /m
	cd ..

A more complex situation occurs if the file on which the file
system is mounted is a directory.  When referencing ".." from
the root of a file system mounted on a directory, ".." must be
looked up in the mounted-on directory.  This can cause problems
if the mounted-on directory and the root of the mounted file
system have different permissions, for instance:

	(as the super-user)
	mkdir /m
	chmod 700 /m
	mount /dev/hp0g /m

	(as a regular user)
	cd /m
	cd ..

results in "..: Permission denied".  The error message occurs
because the user does not have search permission in /m to look
up "..".  The problem is more confusing if /usr is substituted
for /m and a user trys to do a pwd from his login directory.

My proposed solution is as follows.  To solve the first problem,
simply check in smount() and sumount() that the mounted-on file
is a directory.  To fix the second problem, change nami() so that
when ".." is referenced from the root of a mounted file system,
the access check is skipped (instead of "goto seloop" at the bottom
of nami(), goto another label which would be defined a few lines
down from seloop).  I have not implemented either of theses
solutions; I would like comments first.  Is this really a problem
or is it a feature?  Has anyone else noticed it and/or fixed it?

					Bill Shannon
					decvax!shannon or
					CSVAX.shannon at Berkeley