From jkh@time.cdrom.com  Wed Jun 19 04:13:40 1996
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA07035
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 19 Jun 1996 04:13:39 -0700 (PDT)
Received: (from jkh@localhost) by time.cdrom.com (8.7.5/8.6.9) id EAA29196; Wed, 19 Jun 1996 04:13:32 -0700 (PDT)
Message-Id: <199606191113.EAA29196@time.cdrom.com>
Date: Wed, 19 Jun 1996 04:13:32 -0700 (PDT)
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Reply-To: jkh@time.cdrom.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: Permission for .. in NFS mounts is somewhat non-intuitive
X-Send-Pr-Version: 3.2

>Number:         1336
>Category:       kern
>Synopsis:       Permission for .. in NFS mounts is somewhat non-intuitive
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jun 19 04:20:01 PDT 1996
>Closed-Date:    Fri Feb 21 14:08:33 PST 1997
>Last-Modified:  Fri Feb 21 14:09:03 PST 1997
>Originator:     Jordan K. Hubbard
>Release:        FreeBSD 2.2-CURRENT i386
>Organization:
- Jordan Hubbard
  FreeBSD Project
>Environment:

Two machines, client and server.  The following permissions for /u exist
on each:

client-> ls -lgd /u
drwxr-x---  2 root  wheel  512 Jun 19 04:02 /u

server-> ls -lgd /u
drwxr-xr-x  2 root  wheel  512 Jun 19 04:02 /u

The following NFS mount has also been done:

	client-> mount server:/u /u

>Description:

	If an ordinary user (e.g. not root and not in group wheel) on
	the client attempts to do a pwd(1) in /u, the operation will
	fail.  This appears to be due to the fact that pwd walks up
	the directory hierarchy by opening ".." and the permissions
	of the mount mount rather than the mounted directory are checked.

	If nothing else, this violates the principle of least surprise and
	can be a very non-obvious problem for the user given that the mount
	point permissions are obscured.

>How-To-Repeat:

	See above.
>Fix:
>Release-Note:
>Audit-Trail:

From: J Wunsch <j@uriah.heep.sax.de>
To: jkh@time.cdrom.com
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/1336: Permission for .. in NFS mounts is somewhat non-intuitive
Date: Thu, 20 Jun 1996 21:38:31 +0200 (MET DST)

 As Jordan K. Hubbard wrote:
 
 > Two machines, client and server.  The following permissions for /u exist
 > on each:
 > 
 > client-> ls -lgd /u
 > drwxr-x---  2 root  wheel  512 Jun 19 04:02 /u
 > 
 > server-> ls -lgd /u
 > drwxr-xr-x  2 root  wheel  512 Jun 19 04:02 /u
 > 
 > The following NFS mount has also been done:
 > 
 > 	client-> mount server:/u /u
 > 
 > >Description:
 > 
 > 	If an ordinary user (e.g. not root and not in group wheel) on
 > 	the client attempts to do a pwd(1) in /u, the operation will
 > 	fail.
 
 This is nothing special to NFS mounts, it's a very generic mount
 problem.  Try making your /usr 0700 in single-user mode, and go
 multi-user...
 
 You should never make mount points anything else the 755 (or 555).
 They are overshadowed with the mount permissions from the newly
 mounted resource anyway, so the actual permissions of the underlying
 mountpoint are largely irrelevant as long as they allow all intended
 access.
 
 -- 
 cheers, J"org
 
 joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
 Never trust an operating system you don't have sources for. ;-)

From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/1336: Permission for .. in NFS mounts is somewhat non-intuitive 
Date: Thu, 20 Jun 1996 17:29:47 -0700

 > This is nothing special to NFS mounts, it's a very generic mount
 > problem.  Try making your /usr 0700 in single-user mode, and go
 > multi-user...
 > 
 > You should never make mount points anything else the 755 (or 555).
 > They are overshadowed with the mount permissions from the newly
 > mounted resource anyway, so the actual permissions of the underlying
 > mountpoint are largely irrelevant as long as they allow all intended
 > access.
 
 But..  That's basically my point - it's *not* overshadowed in the ".."
 case, and this is very counter-intuitive, if not an outright bug.
 
 					Jordan
State-Changed-From-To: open->feedback 
State-Changed-By: scrappy 
State-Changed-When: Tue Oct 22 21:13:33 PDT 1996 
State-Changed-Why:  

Has this been addressed? 

State-Changed-From-To: feedback->open 
State-Changed-By: scrappy 
State-Changed-When: Tue Oct 22 21:35:51 PDT 1996 
State-Changed-Why:  

Problem still exists... 
State-Changed-From-To: open->closed 
State-Changed-By: mpp 
State-Changed-When: Fri Feb 21 14:08:33 PST 1997 
State-Changed-Why:  
Jordan said to go ahead and close it. 
>Unformatted:
