krb5 library missing functions for collections

[Charles Hedrick]

I think you can actually do that now. But I’m not convinced it’s worth it. You can tell rpc.gssd to look in a specific directory. The default is /tmp then /run/user/%U. You’d probably want to reverse the order.

But these are used after GSSAPI, so in practice they probably wouldn’t get used.

But wait, there more. At least in our environment, GSSAPI will use gssproxy. I think you could configure it to look in some appropriate special cache. You can give it more than one, so you could tell it to use a cache in /run/user/%U if it exists, otherwise the default cache. But you’d still have the problem that it might pick the wrong thing from the default cache, so to get definite behavior, you’d need to use /run/user all the time. Then you have to make sure there’s something reasonable there by default. So you’d want a PAM module to make a copy of your login credentials there by default, since you don’t want to require every user to do a manual kinit. And of course your renewal code would need to renew that along with your primary credentials.

We have code to do all of this if you really wanted to, but it seems like excessive complexity. Ccselect is more straightforward.

I think the separate credential location only starts to make sense if you can select on a per-process basis which to use. And even then I think you’d normally point it to a credential in the default location. Basically the moment you can tell the kernel which credential to use, you can give it a specific credential, and the issue with collections goes away.

> On Jul 26, 2019, at 11:22 AM, Greg Hudson <ghudson at mit.edu> wrote:
> 
> On 7/26/19 9:09 AM, Charles Hedrick wrote:
>> I’ve submitted a feature request to fix the default ccselect plugin so
>> it reads /etc/k5identity if the user doesn’t have one or it doesn’t
>> apply. Also, you’d need to recognize ${username}. That would let me
>> specify a policy for NFS credentials, which could conceivably even
>> differ for different file servers. I think that’s the best that can be
>> done with the current kernel.
> 
> A possible pure-userspace solution is to establish a local directory per
> user in a well-known location, where users (or some agent operating as
> the user's uid) can copy a ticket cache into in a well-known filename.
> If rpc.gssd finds a cache there, it could use it in preference to
> picking from the user's collection.  This doesn't give the kind of
> per-process control you can get from AFS's pagsh, but it does give
> control to users as opposed to a root-owned file like /etc/k5identity.
> On machines using systemd, /run/user/uid could be leveraged for this
> purpose, although that directory will only exist while the user is
> logged in (so not for cron jobs).