> No. That doesn't make sense for network-based filesystems. You don't
> want a single RPC credential to be shared among all the users, since
> that requires the client to choose one that is 'the correct user auth
> for reading this file'. If you have some sort of uid/gid mapping, ACLs
> or --worse yet-- des/kerberos style authentication, then such a
> selection is not obvious. (Imagine if the kerberos token suddenly
> expires)
... and? Suppose that users foo and bar are accessing the file. foo has
credentials alive and well, but bar got them revoked. Now, foo accesses a
piece of file. Data is read and cached. Into the inode's i_data. Where bar
can pick them without any calls to server. See the problem? We are
_already_ sharing the cache. And since file permissions are _not_
range-based...
> As for holding the file handle in the address_space structure, then
> this becomes equivalent to placing it in the inode structure if I
> correctly read the scheme you're proposing. This has been discussed,
No. _If_ you want to enforce strictly server-side credentials checks you
have to split the page cache (see above). _Then_ you can (very logically)
place it into struct file (->private_data). If you share cache you can as
well forget about credentials on read.
There's nothing magical about address_space in inode - moreover, I think
that the right way is to have do_generic_file_read taking address_space as
a parameter. That would mean that NFS should call it with different
arguments and that's _exactly_ what you want. Moreover, that way we can
have cache shared between the openers that have the same credentials.
-
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/