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

[xguan@reliancememory.com]

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

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. 

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

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. 

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

Thank you!

Ximeng (Simon) Guan