lkml.org 
[lkml]   [1999]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: 2.3.30 linuxNFS import is broken (Screwed up NFS/RPC credentials)
From
>>>>> " " == Alexander Viro <viro@math.psu.edu> writes:

> On Wed, 22 Dec 1999, Trond Myklebust wrote:

>> 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...

I agree you cannot be perfect without cache splitting. I'm not
advocating this. We could improve access checking to the page cache
significantly --even in NFSv2-- by for example calling for a 1-byte
dummy read of the file in 'nfs_open()' if the file is to be opened for
reading. (Writing can of course not be handled like this).

Once you've opened the file though, whose credentials do you choose?
Are you advocating a pool of credentials held in the inode structure?
It's feasible, but I don't see why that would be cleaner. The inode is
a shared structure, so why clutter it up with user-specific
information, when you already have an alternative struct for keeping
that sort of info?

Finally, what is the interest of allowing users to spoof the server?
Granted that spoofing the client into allowing access to the page
cache can be damaging enough, but why should we go out of our way to
make it possible to spoof the server as well?

> 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.

My objection to your point about moving the file handle into struct
address_space was not motivated by concerns about credentials, but
rather to the appropriateness of sticking a path-dependent object such
as the file handle into the inode.

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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.060 / U:0.792 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site