On 10/30/06, Steven M. Bellovin <smb@cs.columbia.edu> wrote:
> 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.

Please be aware that, WRT NFS, MFS had the same problems (or at least
it seems so from a quick code review).

As regards the OpenOffice problem, that's another (completely
different, I believe) story and it shall be fixed, not hidden.

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>
The Julipedia - http://julipedia.blogspot.com/