On Thu, Jun 15, 2000 at 06:00:17PM +0200, Trond Myklebust wrote:
> >>>>> " " == Roman V Shaposhnick <vugluskr@unicorn.math.spbu.ru> writes:
>
> > 1.2. nfsfh.c: a lot of changes and not only in interface but
> > also
> > in how subtrees are being checked. Trond, please take a
> > look at this beast ( it is from your forest ;). I'm
>
> Actually I'm not really the head shrubber for the server,
> but I'll try to give a few immediate impressions. I'll see if I can look
> more carefully through things this weekend.
Ok. Thanks.
> My first and immediate question though was whether you think the
> struct fhandle is generic enough?
Well, I hope it is. I can say that it is like 4-d coordinates. Where
'id' is a 3-d space component and 'version' is a time coordinate. I guess
that this information is sufficient to reference each single object in
a given filesystem. Note also that when I'm saying 'object' I mean
something from where data is coming.
> I know that a lot of people are
> interested in using Linux boxes as SMB/NFS gateways for instance. Are
> you considering this sort of issue?
If one would be able to implement SMB objects renumbering than this will
fit nicely into what I'm trying to do. From what I know about SMB there
are NFS-like filehandles. If so, I see no problem in using them as
'id' or even retrieve 'version' from them.
> Secondly: are there any plans for making a 'toolbox' in the VFS in
> order to make implementing filehandles easier for filesystem
> maintainers? A lot of your code in fs/ext2 seems as if it could be of
> benefit to others.
Of course. For now I can think of two different toolboxes -- one for
classic device-based filesystems and one for the network-based. But it
seems that time has not come yet to do this kind of generalization.
Mainly, because for now I'm just trying to discuss an approach not the
particular aspects of coding and code infrastructure. OTOH, I also do not
want to overlook any relevant aspects of what I'm trying to implement
thus I've started with ext2 and the next goal will be NFS-NFS reexports.
> Thirdly: I'm a bit uneasy about the security side of things. A nice
> feature of the existing scheme is that we check whether or not a file
> lies within the exported tree or not (we do this by saving the inode
> number of the parent directory in the file handle, so that we can walk
> the dentry tree back up).
Well. Here we come to the difference ( at least from my point of view )
between NFS filehandles and VFS filehandles: VFS filehandles are very
minimalistic in the sense of what information can be digged from them.
And there is nothing wrong if for some protocols ( like NFS ) the
knowledge of a filehandle is insufficient. E.g. in case of NFS for
the purposes of security we would like to know parent directory
for any given file -- that's ok, we can just add an additional VFS
filehandle to the NFS one that will represent file's parent.
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.
> In your scheme, I can just guess inode numbers and then feed you
> spoofed filehandles in order to get access to files that lie outside
> the exported area.
I may be wrong here, but I think that spoofing is whole different story.
Again -- I do understand that for some NFS implementations we ought to
place two(or 1.5) VFS filehandles into one NFS filehandle. There is nothing
wrong with that. btw, I was unable to find any strict specifications
for that kind of security checks. Is it just a matter of a bad luck or is it
implementation dependent ?
> It means for instance that exporting
> /foo a(ro)
> /foo/writable a(rw)
> is tantamount to making /foo a writable partition, since I can just
> lookup the inode number in /foo, and then rewrite the handle to look
> as if it came from /foo/writable.
Well, for one I can be totally sure -- existing scheme can be implemented
( or emulated ) using VFS filehandles. We just need two ( 1.5 ) of them.
That's it.
Thanks for the quick feedback. And hope to hear from you after the weekend.
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 Jun 23 2000 - 21:00:10 EST