>>>>> " " == 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.
My first and immediate question though was whether you think the
struct fhandle is generic enough? 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?
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.
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).
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.
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.
Cheers,
Trond
-
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