Default libkrb5 ccache location

[Lennart Poettering]

On Fri, 26.07.13 13:57, Stephen Gallagher (sgallagh at redhat.com) wrote:

> This would help us out on the 'su -l' and 'sudo -i' cases, but it
> still potentially leaves us with two problems that I'm not sure how to
> solve (without breaking the XDG_RUNTIME_DIR lifecycle definition).
> 
> 1) https://bugzilla.redhat.com/show_bug.cgi?id=987792 has a problem
> where a user is logging in through SSH with delegated Kerberos
> credentials and is using AFS. After login is complete, his new session
> is available with the credential cache dir in place, but unlike in
> Fedora 18 and earlier, the KRB5CCNAME variable is not available to
> other PAM modules prior to pam_systemd, meaning that his
> pam_afs_session.so does not get set up correctly. It's presumed that
> the reason for this is that SSH sees that it can't create the cache on
> disk yet, so it waits and does so later.

I am not sure I grok this.

So ssh is supposed to store the tickets in XDG_RUNTIME_DIR but you don't
want to patch it to create the dir the same way as the krb PAM module
does?

Doesn't SSH and the PAM module use the same code to store the tickets in
the cache? This really sounds like something that could be shuffled out
between krb, pam, sshd, no? Or am I totally not grokking this?

> 2) We still need to consider use-cases where a cron job or other
> long-running service needs to use credentials given to it by the user,
> though they are no longer signed in. With the current approach, we
> still need to be concerned that the /run/user/UID directory may just
> cease to exist if there are no more active sessions on the machine.

I am pretty sure we should be careful with leaving around runtime data
of a user in /run if he's not logged in. He should not be able to
consume resources unrestricted unless this is OK'ed explicitly by the
admin.

logind knows the concept of "lingering" user. If a user is lingering the
life-time of its runtime resources is from boot-time to shut-down,
rather than only as long as he is logged in. The cron case sounds like
something which could be handled with that. "loginctl enable-linger
foobar" will enable this linger state for a specific user. DEfaults to
off, only root can alter this.

Note that this might cause other resources of the user to stay around
too, it's not just something that affects the life-cycle of
XDG_RUNTIME_DIR and nothing else. For example, in the longer run this
will also mean that the user may have user services running longer than
just during the login.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.