Subject: Re: MNT_NOSHARE for non-exportable fs [was: Removing tmpfs'
To: Bill Studenmund <wrstuden@NetBSD.org>
From: Steven M. Bellovin <smb@cs.columbia.edu>
List: tech-kern
Date: 10/25/2006 11:42:03
On Wed, 25 Oct 2006 08:21:35 -0700, Bill Studenmund <wrstuden@NetBSD.org>
wrote:

> On Wed, Oct 25, 2006 at 09:11:50PM +0900, YAMAMOTO Takashi wrote:
> > > > - why "share" rather than "export"?
> > > 
> > > I chose "share" because "export" is too tightly coupled with NFS. However, I'm
> > > sure my point of view can be swayed ;-)
> > 
> > it's actually tightly coupled with nfs, isn't it?
> > eg. how can it prevent smbd or apache from exporting the filesystem?
> 
> We teach apache or smbd to look for it?
> 

Doing this strikes me as a really, really bad idea.

I agree that we need better permission semantics; I don't agree that this
is the way to do it.  What I do and don't want accessible via NFS, Apache,
Samba, and what have you has little or nothing to do with file system
boundaries -- those, with rare exceptions, are artifacts of a particular
set of system implementation choices.  It's only been, what, two years
since the default NetBSD installation changed from the classic {/,/usr}
model to a single file system model.  Does that mean that my security
model has to change as well?

The current discussion boils down, ultimately, to an implementation
restriction in one of our file system types.  If someone were to put in
the necessary code tomorrow, it shouldn't change what's being made
available to outsiders.

What I really want, from a security perspective, is a way to say with high
assurance "export this tree and that one over there, and nothing else".
That's a very different requirement.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb