From svdb@inferno.stuiver.net  Sat Jun 15 06:30:52 2002
Return-Path: <svdb@inferno.stuiver.net>
Received: from inferno.stuiver.net (t-indiv8-234.athome.tue.nl [131.155.242.234])
	by hub.freebsd.org (Postfix) with ESMTP id 1EC4737B40A
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 15 Jun 2002 06:30:46 -0700 (PDT)
Received: by inferno.stuiver.net (Postfix, from userid 1106)
	id BABED63; Sat, 15 Jun 2002 15:18:49 +0200 (CEST)
Message-Id: <20020615131849.BABED63@inferno.stuiver.net>
Date: Sat, 15 Jun 2002 15:18:49 +0200 (CEST)
From: Serge van den Boom <svdb@stack.nl>
Reply-To: Serge van den Boom <svdb@stack.nl>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: '..' at mountpoint is subject to the permissions of the shadowed dir
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         39329
>Category:       kern
>Synopsis:       [mount] '..' at mountpoint is subject to the permissions of the shadowed dir
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jun 15 06:40:01 PDT 2002
>Closed-Date:    Wed Sep 22 01:03:14 UTC 2010
>Last-Modified:  Wed Sep 22 01:03:14 UTC 2010
>Originator:     Serge van den Boom
>Release:        FreeBSD 4.5-RELEASE i386
>Organization:
Eindhoven University of Technology
>Environment:
System: FreeBSD inferno.stuiver.net 4.5-RELEASE FreeBSD 4.5-RELEASE #0: Sun Mar 17 04:23:07 CET 2002 svdb@inferno.stuiver.net:/usr/src/sys/compile/INFERNO i386

>Description:
If you have a dir which is not readable by someone, and you mount a
filesystem at that location, the permissions the new filesystem gives to the
dir will be the ones used. Only when you try to access '..', which appears
to be generated by the kernel to point to the parent dir of the mount
location, the permissions of the original dir will be used to determine
if you're allowed to.

>How-To-Repeat:
# mkdir /mnt/tmp
# chown root:wheel /mnt/tmp
# chmod 700 /mnt/tmp
# mount somefs /mnt/tmp
# chmod 755 /mnt/tmp
# ls -lad /mnt/tmp/.*
drwxr-xr-x  4 root  wheel  512 Jun 15 15:20 /mnt/tmp/.
drwxr-xr-x  6 root  wheel  512 Jun 15 15:20 /mnt/tmp/..

$ ls -lad /mnt/tmp/.*
ls: /mnt/tmp/..: Permission denied
drwxr-xr-x  4 root  wheel  512 Jun 15 15:20 /mnt/tmp/.

>Fix:


>Release-Note:
>Audit-Trail:

From: Lyndon Nerenberg <lyndon@orthanc.ab.ca>
To: freebsd-gnats-submit@freebsd.org, svdb@stack.nl
Cc:  
Subject: Re: kern/39329 '..' at mountpoint is subject to the permissions
         of the shadowed dir
Date: Sun, 06 Oct 2002 13:45:58 -0600

 While this behaviour is non-intuitive, it has existed in UNIX going back
 to at least 1984. I've seen it in BSD and SVR[0123] systems, and I
 suspect the kernel has behaved this way since the beginning. Because of
 this legacy I don't think this can be called a bug, and therefore this
 PR should be closed.
 
 It might be worth adding a note to mount(2), though.
 
 --lyndon
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/39329

From: Serge van den Boom <svdb@stack.nl>
To: Lyndon Nerenberg <lyndon@orthanc.ab.ca>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: kern/39329 '..' at mountpoint is subject to the permissions   
      of the shadowed dir
Date: Mon, 7 Oct 2002 00:24:00 +0200 (CEST)

 On Sun, 6 Oct 2002, Lyndon Nerenberg wrote:
 > While this behaviour is non-intuitive, it has existed in UNIX going back
 > to at least 1984. I've seen it in BSD and SVR[0123] systems, and I
 > suspect the kernel has behaved this way since the beginning. Because of
 > this legacy I don't think this can be called a bug, and therefore this
 > PR should be closed.
 >
 > It might be worth adding a note to mount(2), though.
 
 If things would never be changed because "they always behaved this way",
 nothing would ever change. A historical bug is still a bug.
 That being said, whether this is or is not a bug is still a matter of what
 is defined as the "correct behavior". Unless there has somewhere in the
 past been made some concious decision in either direction, I would think
 there is still room for discussion.
 
 My arguments in favour of considering this as incorrect behaviour:
 - It is inconsistent. You access everything else in the dir by the permissions
   of the mounted dir, while '..' is accessed by the permissions of the
   mountpoint.
 - It is counter-intuitive.
   Together with the previous point, this is probably the reason I thought
   it was a bug in the first place.
 - It's very unlikely changing this behaviour will break anything.
   After all, only '..' is effected, and generally accessing '..' would only
   be possible in more cases now. This isn't a security risk either, as you
   can in the currect situation always address the dir as an absolute path
   in the cases you could read '..' after the change.
 - If you want to change the permissions of '..' as it is now, you would
   need to unmount and remount the device.
 
 I don't think the issue is very important as the "feature" is easilly
 worked around once you know it's there. But I consider it wrong nonetheless.
 
 I'll gladly hear what you decide.
 
 Greetings,
 
 Serge
 
 
 

From: Lyndon Nerenberg <lyndon@orthanc.ab.ca>
To: Serge van den Boom <svdb@stack.nl>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: kern/39329 '..' at mountpoint is subject to the permissions of the shadowed dir 
Date: Sun, 06 Oct 2002 20:08:32 -0600

 I don't disagree with you. I, too, think the behaviour is a bit strange.
 However, it has survived through at least one complete re-implementation
 of namei and the filesystems (i.e. BSD), which makes me wonder if there
 is a valid reason for the behaviour. Kirk McKusick is probably one of
 the few people who can answer that question.
 
 --lyndon

From: Serge van den Boom <svdb@stack.nl>
To: Lyndon Nerenberg <lyndon@orthanc.ab.ca>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: kern/39329 '..' at mountpoint is subject to the permissions of
 the shadowed dir 
Date: Mon, 7 Oct 2002 16:16:05 +0200 (CEST)

 On Sun, 6 Oct 2002, Lyndon Nerenberg wrote:
 > I don't disagree with you. I, too, think the behaviour is a bit strange.
 > However, it has survived through at least one complete re-implementation
 > of namei and the filesystems (i.e. BSD), which makes me wonder if there
 > is a valid reason for the behaviour.
 I suspect that since the original '..' entry is used to determine where
 '..' goes to, the 'usual' code would read it in its original context,
 i.e. the original dir.
 Using the permissions of the new dir might be less than trivial, which may
 be the reason it is still as it is. Maybe it was something "to do later".
 That it had been that way in the earlier implementation of namei and the
 filesystems might have been more of an excuse than a reason for the later
 implementor(s). However, this is only speculation.
 
 > Kirk McKusick is probably one of the few people who can answer that
 > question.
 I take it he was one of the people involved in the implementation of namei
 and the filesystems currently in use? I think a mail in his direction
 couldn't hurt.
 
 Serge
 
 
State-Changed-From-To: open->feedback 
State-Changed-By: arundel 
State-Changed-When: Mon Aug 16 19:09:35 UTC 2010 
State-Changed-Why:  
Does this issue still exist? I wasn't able to reproduce the problem running a 
recent HEAD checkout (r211163): 

# mkdir /mnt/tmp 
# chown root:wheel /mnt/tmp 
# chmod 700 /mnt/tmp 
# mount -t msdosfs /dev/da0 /mnt/tmp 
# chmod 755 /mnt/tmp 
# ls -lad /mnt/tmp/.* 
drwx------  1 root  wheel  4096 Jan  1  1980 /mnt/tmp/. 
drwxr-xr-x  5 root  wheel   512 Aug 16 21:05 /mnt/tmp/.. 
$ ls -lad /mnt/tmp/.* 
ls: /mnt/tmp/.*: Permission denied 

http://www.freebsd.org/cgi/query-pr.cgi?pr=39329 

From: Jilles Tjoelker <jilles@stack.nl>
To: bug-followup@FreeBSD.org, svdb@stack.nl, arundel@freebsd.org
Cc:  
Subject: Re: kern/39329: [mount] '..' at mountpoint is subject to the
 permissions of the shadowed dir
Date: Mon, 16 Aug 2010 22:35:57 +0200

 I do not remember any change that would affect this, and indeed I can
 reproduce this on 9-current. With ufs (via mdmfs) and tmpfs, this
 proceeds similar to what arundel has posted. With msdosfs, the chmod
 command silently does nothing (as is also visible in the output), so it
 is necessary to use the -m option to set the permissions, like
   mount -t msdosfs -o -m=755 /dev/md0 /mnt
 However, in all three cases the result is the same: an ls -la by a
 regular user shows an entry for . and complains about Permission denied
 for ..
 
 -- 
 Jilles Tjoelker
State-Changed-From-To: feedback->open 
State-Changed-By: arundel 
State-Changed-When: Mon Aug 16 20:49:39 UTC 2010 
State-Changed-Why:  
Jilles Tjoelker confirmed that this PR is still an issue in 9-current. 

Sorry for the noise. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=39329 

From: Oliver Fromme <olli@lurza.secnetix.de>
To: freebsd-bugs@FreeBSD.ORG, bug-followup@FreeBSD.ORG, svdb@stack.nl,
        arundel@FreeBSD.ORG
Cc:  
Subject: Re: kern/39329: [mount] '..' at mountpoint is subject to the ?permissions of the shadowed dir
Date: Tue, 17 Aug 2010 15:12:33 +0200 (CEST)

 arundel@freebsd.org wrote:
  > Synopsis: [mount] '..' at mountpoint is subject to the permissions of the shadowed dir
 
 That's not a bug.  It's supposed to work that way, and it
 works like this in all UNIX variants that I'm aware of.
 In fact I think it would be a bug if the behaviour was
 changed.  That might even break some legitimate uses of
 the feature.
 
 It is clearly documented in the mount(8) manual page:
 
     After a successful mount, the permissions on the original
     mount point determine if '..' is accessible from the mounted
     file system.  The minimum permissions for the mount point
     for traversal across the mount point in both directions to
     be possible for all users is 0111 (execute for all).
 
 This PR should be closed.
 
 Best regards
    Oliver
 
 -- 
 Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
 Handelsregister: Registergericht Muenchen, HRA 74606,  Geschftsfuehrung:
 secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mn-
 chen, HRB 125758,  Geschftsfhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart
 
 FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
 
  > Can the denizens of this group enlighten me about what the
  > advantages of Python are, versus Perl ?
 "python" is more likely to pass unharmed through your spelling
 checker than "perl".
         -- An unknown poster and Fredrik Lundh
State-Changed-From-To: open->closed 
State-Changed-By: arundel 
State-Changed-When: Wed Sep 22 00:55:52 UTC 2010 
State-Changed-Why:  
The responses to this PR along with the CAVEATS section of the mount(8) manual 
suggest that the issue reported by the originator of this PR is in fact not a 
bug, but historic behaviour. 
Changing it would break compatibility with every UNIX like operating system 
all the way back to Version 1 AT&T UNIX. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=39329 
>Unformatted:
