[Bug 2815] please set KRB5CCNAME to collection

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2815

--- Comment #2 from Charles Hedrick <hedrick at rutgers.edu> ---
That would solve the problem I'm reporting. It would also complicate my
life for other reasons, but I can deal with it.

What sssd seems to do if you login with PAM is create a random
subsidiary cache, make it primary, and set KRB5CCNAME to the
collection.

I agree that changing the primary has issues, but it's the lesser evil.
It's a defect in design of the Kerberos libraries. If you don't create
a new cache and make it primary, you can end up stomping on an existing
credential with a different principal, potentially breaking NFS (though
protecting against that also requires a patch to rpc.gssd that I've
just requested). The real problem is that the primary is global for the
user, and not per-session. That is in turn a result of the fact that
Linux doesn't have a very good way of defining sessions.

The reason not setting KRB5CCNAME would complicate my life is that I
have a daemon that renews principals. I have to know which principals
are still in use, to not renew and eventually clean up ones not in use.
Currently I do it by checking KRB5CCNAME for all processes. If you
don't set KRB5CCNAME it's going to be hard to know whether a process is
using Kerberos or not, though I have a design that will do an
approximation. I agree that in principle KRB5CCNAME doesn't need to be
set. The library defaults to what's in krb5.conf. However at the moment
everything actually does set it, so not doing so in sshd will require
special-case handling. It would be easier for me if you explicitly set
it to what's in krb5.conf. Basically I'd prefer your code to work the
same as sssd's, so we get the same behavior whether the user types a
password or comes is by virtue of a Kerberos ticket.

I guess we're a bit unusual, in that (1) our home directories are
kerberized, so we can't afford to lose the ticket, (2) some of my users
are pretty unsophisticated, so we don't want to explain tickets and
kinit, and (3) my staff are using 2FA. I've had to construct some
support code. I'm trying to get gssd, sssd, and sshd to adopt some
changes so that things will work by default. At the moment I have my
own pam module that changes KRB5CCNAME to the collection if it's a
specific cache, and I copy the new cache to a separate location where
gssd will see it, even if the primary cache ends up being something
else. (I've suggested a change to gssd that will make NFS work if
there's a ticket for the user's primary principal, even if it's not
currently primary. It just requires using gssapi in a slightly
different way.) The sssd maintainers have agreed to handle automatic
renewal in the long run.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.