Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote:
> I thought you were passing a generic cred as an argument? It should be
> possible to convert that into an rpc_cred.
Indeed I am, but I think I haven't gotten my questions across.
Take the rpc_cred struct as an example. It contains some stuff that is
obtained by taking the credentials open was supplied and munging them into
other things perhaps by contacting a remote auth server. Now, assuming that I
can replace rpc_cred by, say, a key struct with dangly bits, most of the
fields can be replaced by the key struct fields (cr_hash, cr_lru, cr_rcu,
cr_expire, cr_flags, cr_count) or cred struct fields (cr_uid possibly). But
that still leaves cr_auth and cr_ops, which can be dangled from a key if
that's okay, but how tied are these to a particular open? That I'm not sure of.
However:
(1) If I then attach such a key to the cred struct, NFS would have to perform
a search every time it wants to use the cred. This might not be so bad,
as the keyring search algorithm uses RCU to do all its locking, and I
would guess there won't be that many keys.
I could attach a cache to the cred struct so that any key that got used
gets added to it. The cache could be in the form of a keyring.
(2) If I require that the keyrings pointed to by a cred struct be searched
each time an NFS op takes place, then the credentials being used by an
open file can change as the membership of the keyrings changes - which
I'm fairly sure is the wrong thing to do.
The problem is that the cred struct wants itself and all its dangly bits
to be purely COW, but keyrings don't work like that because their
contents need to be alterable.
I could work around this by duplicating the cred struct for each open
call, and allowing a fs to attach its own keys or whatever directly to
it, but if we do that, we may as well use struct file.
> In the long run, we should get rid of the rpc_cred in the NFS layer, and
> replace it with the generic creds, but for the short term, converting
> one into the other in the NFS code should be acceptable.
Agreed, but I'm trying work out a way of avoiding a couple of problems (namely
having the creds on an open file changing and having to perform a search), if
indeed they are deemed to be problems.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
