On Fri, 2017-08-11 at 10:22 -0400, Jeff Layton wrote:
> I think I wasn't clear here. I'm not proposing that you move everyone
> to
> KEYRING: credcaches. This would not be a visible change to userland.
> We'd still use rpc.gssd to upcall for creds.
>
> What I'm saying is that instead of storing the creds in a hashtable
> like
> we do today, we'd just stash them in one of the keyrings hanging off
> of
> struct cred.
>
> Change all of the authgss_ops operations to do query/store from the
> appropriate keyring directly. With that, the effective lifetime of
> GSSAPI creds would be bounded by the lifetime of the keyrings that
> hold
> references to it.
>
> We'd probably need a new key_type for this to ensure that this
> couldn't
> be manipulated directly from userland. Or...maybe you'd still want to
> allow userland to destroy the creds? No need for a new syscall with
> that
> -- they can just do a "keyctl unlink". There are a lot of options
> here.
>
> It's a non-trivial amount of work though (rpcauth_lookupcred() on
> down
> would probably need to be reworked) and I haven't looked at it
> detail.
> Still, it seems like it could be a more modern and cleaner design
> than
> what we have today.
>
The main annoyance with going from a global to a local cache such as
the keyrings is that it makes comparing credentials a lot more work.
Today, because the credentials are essentially unique per server, we
just do pointer comparisons. Once we have non-global caches, we would
need to do more elaborate comparisons to ensure that the uid, gid, and
list of groups match.
That's also why we never made the leap to using 'struct cred', btw...
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@xxxxxxxxxxxxxxx
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
