From: David Howells <dhowells@redhat.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: dhowells@redhat.com, viro@ftp.linux.org.uk, hch@infradead.org,
kwc@citi.umich.edu, jlayton@redhat.com, nickpiggin@yahoo.com.au,
linux-fsdevel@vger.kernel.org
Subject: Re: Caching semi-digested credentials in struct cred
Date: Wed, 24 Oct 2007 18:10:09 +0100 [thread overview]
Message-ID: <2219.1193245809@redhat.com> (raw)
In-Reply-To: <1193237038.7508.4.camel@heimdal.trondhjem.org>
Trond Myklebust <Trond.Myklebust@netapp.com> 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
next parent reply other threads:[~2007-10-24 17:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1193237038.7508.4.camel@heimdal.trondhjem.org>
[not found] ` <1192634425.7573.5.camel@heimdal.trondhjem.org>
[not found] ` <7004.1192630004@redhat.com>
[not found] ` <1248.1193234419@redhat.com>
2007-10-24 17:10 ` David Howells [this message]
2007-10-24 17:52 ` Caching semi-digested credentials in struct cred Trond Myklebust
2007-10-24 18:41 ` David Howells
2007-10-24 19:39 ` Trond Myklebust
2007-10-24 22:22 ` David Howells
2007-10-24 23:09 ` Trond Myklebust
2007-10-25 15:45 ` David Howells
2007-10-25 15:59 ` Trond Myklebust
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2219.1193245809@redhat.com \
--to=dhowells@redhat.com \
--cc=Trond.Myklebust@netapp.com \
--cc=hch@infradead.org \
--cc=jlayton@redhat.com \
--cc=kwc@citi.umich.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).