>>>>> " " == Alexander Viro <aviro@redhat.com> writes:
> On Thu, 15 Jun 2000, Trond Myklebust wrote:
>> 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?
> <raised brows> what, CIFS provides stable identifiers for its
> objects? Since when?
You could do something along the lines of what nfs-server did: a hash
of the filename. Far from perfect, but better than nothing...
>> 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.
> IMO it's a red herring. First of all, that behaviour is, AFAICS
> Linux-specific. IOW, if you rely on that feature and move your
> filesystems to Slowlaris box - welcome to surprise. Besides, it
> makes for an interesting life on clients - rename() may change
> the fhandle and that is Not Good(tm).
> -- NFS stands for "No File Security" for very good reasons...
Read the NFSv4 draft specs. Even Sun now acknowledges that such
behaviour may exist. Linux is not the only system that refuses to
recognize the inode as the second coming.
While I'd be the first person to welcome a file handle that was not
directory specific (makes inode + dentry revalidation on the client 10
times easier) I must admit that there is a point here:
Given the number of Linux newbies who create 1 huge partition on their
single IDE drive and then plonk their entire system on it, I think we
should at least try to make it difficult for outsiders to write to
/etc/passwd. After all it's not more than a week since we discovered
another hole (setuid+capabilities) due to leaving to much up to the
user...
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 : Thu Jun 15 2000 - 21:00:36 EST