From owner-freebsd-hackers Fri Jul 3 03:17:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA29467 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 03:17:30 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA29448 for ; Fri, 3 Jul 1998 03:17:18 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id DAA21943; Fri, 3 Jul 1998 03:17:14 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp02.primenet.com, id smtpd021936; Fri Jul 3 03:17:13 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id DAA15756; Fri, 3 Jul 1998 03:17:09 -0700 (MST) From: Terry Lambert Message-Id: <199807031017.DAA15756@usr04.primenet.com> Subject: Re: permission confusion at mount points To: sthaug@nethelp.no Date: Fri, 3 Jul 1998 10:17:09 +0000 (GMT) Cc: dkelly@hiwaay.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <19506.899446178@verdi.nethelp.no> from "sthaug@nethelp.no" at Jul 3, 98 08:09:38 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Should the mount point really influence permissions this way w/o > > > giving any indication of this? Or is this behavior unintentional? > > > Is it worth a PR? > > > > Its that way in every Unix I've used. Can't think of one that it doesn't > > act up, but somebody would point out the odd system if I was to claim > > more than I know and say *all* unices. > > Yes, I've seen this trip the unwary on many different Unix systems. I've > never seen a reason for *why* it has to be this way. > > Can anybody enlighten us why? The reason is that FS's "cover" mount points. This means that the mount points are evaluated before the "covering" values are discerned. Practically, this means you determine if the person has access to the vnode being covered before you replace it with the vnode doing the covering. I personally think that the idea of mapping a vnode into an existing directory hierarchy should *not* require acess to the existing hierarchy to implement. My idea is that you seperate the act of mapping from the act of lookup; this is a little inconvenience, in that you ignopre the mapping point in favor of that which is mapped. It has the advantage that "X" replaces "Y" instead of "X" predicates "Y". In more simple terms, it means that the mounted FS permissions are checked instead of the mount point permissions before acces is granted. This is really an issue of data hiding more than anything else, since it has to do with when permissions are evaluated. You could look at this as being like VT100 "am"; the value of the permissions are evaluated before the 81st charater instead of after the 80th. There are a number of *very nice* consequences to looking at mapping into the FS namespace this way, starting with the ability to automount removable media into the hierarchy. This is more of an issue for mobile computing and/or CD changers; never the less, the idea has a certain value above and beyond the simple act of dynamic configuration of system resources... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message