Default libkrb5 ccache location

[Simo Sorce]

On Fri, 2013-07-26 at 20:15 +0200, 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?

What I am proposing is that libkrb5 take care of this using a helper and
get our of XDG_RUNTIME_DIR completely given lifetime of the ccache is
not necessarily aligned with that of this directory.

so yeah if we go with my proposal we will have the right component do
the right thing.

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

Same as for /tmp right now, so I do not see much of a difference here.

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

We want this thing to work by default, having normal users to find out
this lingering concept exist because operations that currently works
start failing is already a big failure.

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

I am not sure I understand what's the point here, but I do not think it
is relevant.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York