>>>>> " " == Benjamin C R LaHaise <blah@kvack.org> writes:
> What is the permissable means in the context of NFS to
> determine if two filehandles point to the same object? I'm
If they are identical, you know they point to the same object. If they
differ, you have no way of concluding.
> starting to think that a cleaner means of implementing NFS on
> top of address spaces would be to make NFS return an
> address_spaces per (filehandle, credential) pair, then rip
> struct file out of all address_space_operations and add a
> findpage/getpage operation that would allow NFS to return a
> page in a different address space -- having a call to perform
> "mapping" could be useful for stacking or as a means to
> implement swap spaces (so that IO can be done on the page
> directly to the underlying file).
Why? The 'struct file' is the thing which determines what credentials
we have. We check permissions upon file open, and then store them in
struct file. What would you gain by substituting one structure by
another?
If you're thinking 'I'll just use the file owner for my credentials'
(which was once suggested on nfs-devel), then the rhetorical answer is
'How are you going to detect & cope with root squashing/uid
remapping and such tricks?'.
> I wouldn't care about this if the struct file * was available
> everywhere, but it just isn't needed and it throws up huge
> obstacles in the way of making certain optimizations in the mm
> layer (having struct file * in vma's doesn't make much sense to
> have to traverse the
> file-> dentry->inode->address_space chain just to check if the
> page is cached, when all vm uses can be cleanly solve with an
> address_space pointer sans file), and metadata caching
> (page_cache_read needs a struct file * -- something that's not
> fun to create when you really just want to pass in an
> address_space -- of course it can be worked around by
> implementing it again, but shouldn't simple code be reusable?).
Why create complications? Right now, 'struct file' fits the bill
everywhere without the need for creating bogus structures. It
automatically has the correct credentials and
information. Furthermore, in those circumstances where we don't need
it, we can work around it. NFS, for example, doesn't use
page_getlink() (Yep. I'd even forgotten that myself).
>> BTW going to give us grief under NFS when we try to implement
>> NFS3PROC_ACCESS for
inode-> i_ops->permission().
> Per-filesystem fhandle_to_dentry! Let unix like filesystems
> get clean and efficient handling trivially, and things like FAT
> can surely figure out a decent filehandle by stuffing the
> directory cluster & filename in. Don't go about trying to
> solve all the security problems with NFS -- these are known
> holes that everyone is able to live with.
I believe this idea is already on the knfsd agenda. I doubt this'll be
ready for 2.4.x though...
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 : Mon May 15 2000 - 21:00:12 EST