On Tue, Jun 27, 2000 at 02:05:04PM +1000, Neil Brown wrote:
> On Wednesday June 21, vugluskr@unicorn.math.spbu.ru 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.
Ok. But from my point of view this is just a question of data structures (
int or long or even long long or even void * ). Remember what I was asking
about ? I asked about examples "where my scheme wouldn't work *at all*".
> I suspect there are, or will be, more.
More filesystems with ids longer than 32bits ?
>
> >
> > > 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?
Huh! I'm not a great fan of the beasts like khttpd, but as far as I can
predict, I guess that sooner or later we will get kncpfsd or even ksmbfsd.
I hope to be wrong, but...
> Obviously you have one.
For now ? Yes.
> > > 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.
Ok. I do understand you. But than the first thing we ought to do is to
sit down and write a list of the things not defined in RFC[1094|1813] but
badly needed by Linux community. It's ok. Let's start it. I do not think
that everything what can be found in knfsd sources has a reasonable
explanation ( not talking about implementation at all ).
> As for your "technical comments" in the code:
If you're talking about *my* code than you've got me wrong. I was trying
to draw your attention to your proposal. But have failed ?
> 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.
Well, than we should start to work out:
1. what we *need* from knfsd at a user level besides RFC.
2. interface to fhandle operations.
3. implementation details of stuff like subtrees.
> 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.
I agree, but than they must be real subtrees. Not imaginary knfsd creatures.
I guess, I'm a bit late and Al has explained everything about what should be
done in this direction.
> 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.
No. Or I'm completely out of context.
> Certainly, we will often export whole filesystems and not need to
> connect files, but the option should be there.
And it will be there. But at lower price. I'm not sure but I guess that we
can't proceed without introducing significant interactions between knfsd and
union mount stuff. From my point of view ( I'll try to read recent kernel to
be 99.9% sure ) not only the right way but the only way to cope with the
situation is to create vfsmount for each export. At least this will solve
a problem with subtrees and let us export filesystems in the most natural way.
Thanks,
Roman.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:11 EST