Subject: Re: MNT_NOSHARE for non-exportable fs [was: Removing tmpfs'
To: Cary G. Gray <Cary.G.Gray@wheaton.edu>
From: Steven M. Bellovin <smb@cs.columbia.edu>
List: tech-kern
Date: 10/30/2006 13:44:27
On Mon, 30 Oct 2006 11:56:14 -0600 (CST), "Cary G. Gray"
<Cary.G.Gray@wheaton.edu> wrote:

> On Mon, 30 Oct 2006, Julio M. Merino Vidal wrote:
> > However, it'd be different if this noexport option was set by the file
> > system driver itself (I think this is what others suggested and is
> > what I had in mind a long time ago during the rototill).  This way,
> > tmpfs (or any other file system that wanted to for whatever reason)
> > could say "hey, I don't want to be exported", and then you could not
> > export it in any way.
> 
> At the risk of repetition, let me argue that it what is at issue here is 
> not a security issue, nor is it really about "export".  The question is 
> whether a particular filesystem can provide the guarantees required by a 
> particular application (said application being the NFS server).  It isn't 
> a case of "want", but "can".
> 
> The NFS server code can not correctly export from tmpfs, because tmpfs 
> does not make the required guarantee about persistence of file handles. 
> What is needed here is a way that the NFS code can query whether an 
> underlying filesystem meets its requirements.  But the vocabulary of that 
> query doesn't involve the word "export".
> 
Precisely.  That file system has a {feature,bug,deficiency} with respect
to NFS and a few other features (i.e., the ability of OpenOffice to scan
at).  To the extent we're willing to live with those as semi-permanent
behaviors, we need a way for people to be informed rather than leave them
wondering why things aren't working properly.  Trying to attach security
semantics here is just wrong. 


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