On Thu, Aug 22, 2019 at 02:18:20PM -0700, xg...@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 _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info