Default libkrb5 ccache location

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/26/2013 02:15 PM, Lennart Poettering wrote:
> 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?
> 


My point here was more to highlight that we're currently playing
whack-a-mole to figure out which applications need access to the
directory ahead of the session phase. This was representative in that
it showed a situation where we needed to have access to it right from
the beginning and available to the PAM environment itself.

Essentially, I'm saying we need to have a way to deal with creating it
when it needs to be created, which Simo's proposal does. Having this
helper binary attached to libkrb5 is one way to accomplish it. It's
pretty close to the suggestion I made in a private thread with you a
while ago where I asked for logind to offer us a public API to just
request early creation. Since you expressed concerns with that use of
XDG_RUNTIME_DIR, we've opted in this proposal to just create a
separate directory that is carefully-purposed for only this use to
avoid stopping on the toes of the session-based features.


>> 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.
> 

As Simo noted in the other thread, the availability of credentials
outside the normal user session is an expectation of existing tools.
The exposure here is significantly mitigated by the fact that Kerberos
credentials are time-limited by the KDC.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHywLoACgkQeiVVYja6o6PMKQCdGx9u0//u9ZGXAZj6a0t2J3le
TqEAn0PmVPgaRCvG/rLWxO/TLpy87lNL
=Gjvk
-----END PGP SIGNATURE-----