Re: Caching semi-digested credentials in struct cred

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Trond Myklebust <Trond.Myklebust@...>
Cc: <dhowells@...>, <viro@...>, <hch@...>, <kwc@...>, <jlayton@...>, <nickpiggin@...>, <linux-fsdevel@...>
Date: Wednesday, October 24, 2007 - 1:10 pm

Trond Myklebust <Trond.Myklebust@netapp.com> wrote:


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.


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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: Caching semi-digested credentials in struct cred, David Howells, (Wed Oct 24, 1:10 pm)
Re: Caching semi-digested credentials in struct cred, Trond Myklebust, (Wed Oct 24, 1:52 pm)
Re: Caching semi-digested credentials in struct cred, David Howells, (Wed Oct 24, 2:41 pm)
Re: Caching semi-digested credentials in struct cred, Trond Myklebust, (Wed Oct 24, 3:39 pm)
Re: Caching semi-digested credentials in struct cred, David Howells, (Wed Oct 24, 6:22 pm)
Re: Caching semi-digested credentials in struct cred, Trond Myklebust, (Wed Oct 24, 7:09 pm)
Re: Caching semi-digested credentials in struct cred, David Howells, (Thu Oct 25, 11:45 am)
Re: Caching semi-digested credentials in struct cred, Trond Myklebust, (Thu Oct 25, 11:59 am)