Bug 14322

Summary:	mount respects permissions of underlying directoy!!
Product:	Base System	Reporter:	lkoeller <lkoeller>
Component:	kern	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	3.3-RELEASE
Hardware:	Any
OS:	Any

Description lkoeller 1999-10-14 11:50:01 UTC

	/var is mounted as

	/dev/da0s1g             /var            ufs	rw,userquota=/var/quotas/user.var,              2       2

	from fstab. The permissions of the /var-directory before mounting are

	drwxr-x---  22 root      wheel  -        512 Oct 14 11:07 var

	after mounting

	drwxr-xr-x  22 root      wheel  -        512 Oct 14 11:07 var

	mount showes

	/dev/da0s1g on /var (local, with quotas, soft-updates, writes: sync 118 async 1381)

	Nevertheless a user, not in group wheel gets a permission
	denied when trying a

	ls ..

	in the directory /var

	After going to singel user mode an changing the permissions of the
	mount-directory to 755 the effect vanishes after mounting /var again!

	I think this a bug, that can make a lot of trouble!!!

Fix: 

Don't know!
How-To-Repeat: 
	mkdir /test
	chmod 750 /test
	chown root:wheel /test
	mount .... /test

	try as a user not in group wheel a

	cd /test
	ls -l ..

	you get permission denied for ..

Comment 1 sb 1999-10-26 22:13:27 UTC

The described condition is rather a normal happening; for over ten years I
have always made sure my mount point and the mounted directory share
permissions (UID and mode) in various flavours of UNIX -- I've seen this
happen on Sun computers and ever since I have matched mounted and mount
point permissions.

Not saying it isn't a bug, but it sure can make you scratch your head the
first time you see it :^)

Steve Brown
sb@napanet.net

Comment 2 lkoeller 1999-10-30 10:13:43 UTC

----------

Hello!

In reply to "Steve Brown" who wrote:
 
 > The described condition is rather a normal happening; for over ten years I
 > have always made sure my mount point and the mounted directory share
 > permissions (UID and mode) in various flavours of UNIX -- I've seen this
 > happen on Sun computers and ever since I have matched mounted and mount
 > point permissions.

O.k. perhaps I'm the lucky unknown up to now, but since my first 
contact with FreeBSD in 1993 I've never seen this behavior. I will 
discuss it again with a college at work with a 20 year UNIX sysadmin 
experience.

 > Not saying it isn't a bug, but it sure can make you scratch your head the
 > first time you see it :^)

How true!

Thanks and best regards

Lars
-- 
E-Mail:                                     |  Lars Koeller
  Lars.Koeller@Uni-Bielefeld.DE              |  UNIX Sysadmin
  lkoeller@cc.fh-lippe.de                     |  Computing Center
PGP-key:                                       |  University of Bielefeld
  http://www.pgp.net/pgpnet/www-key.html        |  Germany
----------- FreeBSD, what else? ---- http://www.freebsd.org -------------

Comment 3 lars.koeller 1999-11-02 12:12:15 UTC

In reply to Steve Brown who wrote:

 > The described condition is rather a normal happening; for over ten years I
 > have always made sure my mount point and the mounted directory share
 > permissions (UID and mode) in various flavours of UNIX -- I've seen this
 > happen on Sun computers and ever since I have matched mounted and mount
 > point permissions.
 > 
 > Not saying it isn't a bug, but it sure can make you scratch your head the
 > first time you see it :^)

A little test on our HP Cluster (HPUX 10.20) shows the expeted 
behavior, only the permissions of the mounted directory are valid.
for the accessrights. The underlying directory perms aren't 
valid anymore after the mount.

Does anybody know if this behavior has changed in some older FreeBSD 
version, cause I remember a case where the permissions only of the 
mounted directory are respected!

Is the default behavior mentioned in any manpage? I didn't found 
one!

Regards

Lars
-- 
 Lars Köller       |    Raum   : V0-318 (Tel: 4964)
 UNIX Systemad-    |    E-Mail : Lars.Koeller@Uni-Bielefeld.DE
      ministration |    PGP-Key: http://www.pgp.net/pgpnet/www-key.html
----------- FreeBSD, what else? ---- http://www.de.freebsd.org ---------

Comment 4 kkonstan 2001-06-14 20:39:50 UTC

Hello,

I just tested this on a recent -STABLE and 4.3-RELEASE and
it does not have this "unexpected" behaviour, I also doubt
that anyone is going to fix this for 3-STABLE :>

This PR can be closed

--kkonstan

Comment 5 Warner Losh freebsd_committer

2001-06-15 21:33:58 UTC

State Changed
From-To: open->closed