Re: [RFC] fhandle implementation.

[Neil Brown]

On Wednesday June 21, [e-mail] wrote:
> On Fri, Jun 16, 2000 at 04:48:58PM +1000, Neil Brown wrote:

> > So extracting two longs, giving them names, and passing them to the
> > filesystem just isn't the right idea.  The only reason that the
> > extracting-two-longs code is in there is for back-compatibility.
> 
>    Why ? Just because it doesn't brew coffee for you ? Again: I see no
> point in using opaque data structures where you can survive without it.
> Please, if you have any reasonable counterexamples of where my scheme
> wouldn't work *at all* -- show them. I can agree that sizeof(fhandle)
> is too small and it is unacceptable for some filesystems, but, well,
> show them up.

1/ reiserfs.  They has often said that squeezing the identity of a
   file into 32bit isn't going to work.
2/ sgi-xfs.  I'm pretty sure that they use 64bit inode numbers.

I suspect there are, or will be, more.

> 
> > The filesystem might want to store 64 bit numbers, or several
> > different numbers which are each possible keys (in the case of a
> > filesystem not having a guarnteed key).  The knfsd layer really
> > shouldn't care.
> 
>   I can say that you are very knfsd-oriented. May be that's the main 
> driving force behind your critique.
> 

Definately.

Maybe I am being a bit blind, but what other application do you have
for file handles?  Obviously you have one.  Could you share it with
us?
I had originally imagined these functions being in a "nfsd_operations"
structure, precisely because nfs puts special demands on the filesystem
that a Posix interface does not.

> > Also, ripping outv the "security" stuff is a bit unfriendly.    
> > I think
> > it does have a place, even if you don't think it gives much extra
> > security, and quoting  RFC[1094|1813] isn't really the point.  These,
> > particularly 1094, are very bare-bones protocol descriptions.  There
> > is a lot that they don't say about implementation that can still be
> > very important.
> 
>   What does it mean "very important" ? "very important" for whom ? 
> Damn! We have *standards* some of them are very official some of them
> isn't. But after all, we all know that RFCs _do_ dominate the world, don't
> we? Moreover, as I've already said an existing way of doing security checks
> *is* implementable. See technical comments bellow.

An implementation of NFS means much more than just following the RFC.
Look at the all export options that are available.  Some of them deal
with issues that are beyond the scope of the RFC. Some deal with
issues that should have been but weren't (insecure_locks).
Yes, we should definately follow the RFC as far as it goes, but where
it is silent (as it is on the whole issue of who gets what access
when) we have to add something.

As for your "technical comments" in the code:  The question is which
piece of code is best placed to find the parent of a given file - the
filesystem (which knows all the itty gritty detail) or knfsd.
Currently knfsd does it, but in general, I think the filesystem is in
a better position to know what would work most efficiently.

I could live with knfsd having to encode the parent and the file in
the nfs file handle, but it seems to me that in general, the
filesystem is better able to do it.

> 
> > You said in a separate Email that:
> >   But my strong opinion here is that this kind of trickery should stay on
> >   a protocol level and it should not be integrated into VFS filehandles.
> > 
> > My perspective is:
> >   The need is "given a file(handle), find the parent".  The NFSD layer
> >   can only do this by grabbing a filehandle for the directory as
> >   well.  
> 
>     Why in hell we need parents for plain files ? It is a waste of time,
> it is a waste of memory. It is a place where dragons^H^H^H^H^H deadlocks and
> races live. The only reason I've heard about is that kind of "security". I don't
> think that it is a fair trade[off]. Can you show me any other reason 
> of why should we "connect" files to the  VFS tree ?
> 

It is perfectly natural to want to base access control on subtrees of
the filesystem.  It is also perfectly sensible to give away
minimum-privilege. 
This implies that knfsd should be able to export only part of a
filesystem.  To be able to do this, we need to confirm that a given
file is in a given part of a filesystem.  To do this, we need to be
able to connect a file to the tree.
Certainly, we will often export whole filesystems and not need to
connect files, but the option should be there.

NeilBrown