linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 23:22:00 +0100	[thread overview]
Message-ID: <4350.1193264520@redhat.com> (raw)
In-Reply-To: <1193254764.7515.27.camel@heimdal.trondhjem.org>

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

> > > Use the credential struct as the unique lookup key for an rpc_cred.
> > 
> > That's not good enough.  A cred struct may map to several rpc_creds as I
> > mentioned above.  I suppose the nfs_client struct address could be added
> > to the lookup key.
> 
> Huh? The RPC cred lookup function takes a pointer to an rpc_auth struct,
> which should already be tied to an rpc_client.

So where do you get the rpc_auth struct from?

How about we come at it this way: nfs_readpage() is changed to have a struct
cred * instead of a struct file *.  How do we get the appropriate rpc_auth
struct (assuming it isn't held in the cred struct)?  We need something from
the mapping to use as part of the lookup key, be that an nfs_client or an
rpc_client.

> In the case where keyrings are enabled and a key changes, then we should
> revalidate the rpc_cred and either dump it (replacing it with a new
> cred) or reuse it. We can only cache so much garbage...

You can't necessarily just arbitrarily ditch an rpc_cred just because the key
it was derived from has been replaced.  Someone may have a file open that's
using it.  Unless, of course, you accept that it's okay to change the
credential that an open file is using...  If we're happy to do that, that makes
my life a lot easier.

Also, it occurs to me that if a cred struct acts as a lookup key to find cached
rpc_creds, what controls the lifetime of the latter with respect to the former?

> Possibly, but I'm not accepting any single patch that completely
> rewrites the basic security model of NFS in one fell swoop. If you want
> to change the cred->rpc_cred mapping, then that will be done in
> incremental patches.
> Your first step is therefore to get the generic cred working with the
> _existing_ RPC security model.

I would never have thought of that.

However, there are two points you should consider: firstly, I've a patch that's
a quarter of a Meg just to add struct cred pointers into NFS so that the
appropriate credentials get down into the SunRPC layer rather than using
current's credentials; and secondly, I want some idea of where I'm going.  If
you'd rather, I can just drop the credentials into the NFS VFS methods and
leave it for you to make work.

David

  parent reply	other threads:[~2007-10-24 22:22 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       ` Caching semi-digested credentials in struct cred David Howells
2007-10-24 17:52         ` Trond Myklebust
2007-10-24 18:41         ` David Howells
2007-10-24 19:39           ` Trond Myklebust
2007-10-24 22:22           ` David Howells [this message]
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=4350.1193264520@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).