[OpenAFS] Per-session or per-user (persistent) keyring for Kerberos

[Benjamin Kaduk]

On Thu, Aug 22, 2019 at 02:18:20PM -0700, xguan@reliancememory.com wrote:
> Hello,
> 
> On the recent CentOS 7 clients we brought up, I notice that the default
> Kerberos configuration in /etc/krb5.conf (MIT) has set the default cache to
> be 
> 
> default_ccache_name = KEYRING:persistent:%{uid}
> 
> As a result, multiple login sessions by the same user on the same client
> seem to share the same tickets. 
> 
> Although "unlog" in one session does not seem to affect the token of
> another, "kdestroy" in one session does clean up the cache seen by every
> session of the same UID. (I suspect the token isolation is achieved by
> pam_afs_session.so in my PAM stack by creating a PAG for every login
> session.) 

(Presumably.)

> What seemed a bit surprising to me are:
> 
> A login session can "aklog" to get a new token without typing password, as
> long as there is a different session with the same UID that has obtained a
> TGT. That makes me a bit worried. 

Why are you worried?
The conclusion I draw from reading the systemd discussion on github you
link below should be that linux credentials are de facto per-user, and thus
the kerberos credentials from one session are accessible (including via
aklog) to another session of the same user.

> "krenew" (from the k5start package) seems to be confused. When it wakes up
> and checks the ticket lifetime from the persistent keyring, that lifetime
> may have been extended by a different session from the same UID. Krenew
> decides no renewal is needed and goes to sleep. Then AFS token of that PAG
> expires. A fix I am using is adding a "-a" argument to enforce renewal every
> time it wakes up. 

The confusion seems to stem from the mismatch between per-user Kerberos
configuration and per-session AFS configuration.  Consolidating to per-user
configuration for both would be a natural way to resolve things, though
your workaround can be valid in some scenarios.

> I noticed the unfortunately inconclusive discussion at
> https://github.com/systemd/systemd/issues/7261
> 
> That makes me feel that this community is friendlier and easier to ask
> around. 
> 
> We do not have complications at this moment where different biologic beings
> or differently authenticated logins share the same UID. But I wonder if
> per-user ticket/token is where AFS has decided to accept in the future after
> systemd breaks the per-session assumption and refuses to provide a fix for
> enterprise applications deployed in production. 

AFS is a broader community than just linux, and so is unlikely to force
everyone to per-user semantics just because of one OS.  That said, I'm not
sure that there's even a universal agreement in the community to concede to
per-user semantics; there are various possible approaches depending on
one's goals.  It may be worth documenting a few popular options and
providing supporting PAM configuration/etc. to make it more widely
available to the community.

> If I switch the default ccache to KEYRING:session, will that break anything?
> Any corner cases to which I should pay attention? 

My understanding is that doing so would break the ability of services
spawned from `systemd --user` to access files in AFS.  Whether that
Kerberos configuration for the right choice for you depends on what goals
you're trying to achieve, which is unclear to me.

-Ben