Since we are not using PAGs anymore on most of our systems and instead using UID based logins for tokens, I should retest and see what does and doesn't work with keyrings as I honestly don't recall at this point, and things have changed with the various point releases of RHEL8. One of the challenges when testing is that things can appear to work when in reality, the last login didn't actually destroy all credentials.
My memory does say, though, that on login we did successfully get kerberos tickets in the keyring (aklog may be a different story, though, and I have a note that that didn't work without: KerberosUniqueCCache=yes in sshd.conf, though no more details, stream of thought comments Lol) There's a couple of systems where we still use PAGs so that when a user logouts with multiple logins, their other logins still have tokens. With systemd-login, that may not actually be needed to accomplish said end goal. All future stuff to play with. On Mon, Jul 11, 2022 at 01:20:31PM -0400, Ken Hornstein wrote: > >We went back to using FILE based caches for use along with PAGs. > >Something didn't work right with keyring caches, and I don't recall > >what. > > Ah-HA. I was wondering about that. I suspect you ran into the base > problem that my PAM stack solves, namely that _in_ the PAM stack you're > running as root and that creates a keyring cache owned by root which > doesn't work after you call setuid(). > > It's kind of a challenging corner case; you receive forwarded > credentials in a daemon running as root, but then you have to write > them out as the user. How do you do that at the right point in the > daemon process, especially when they assume after setuid() is called > they have all of the normal rights of a user? My solution was designed > so that after you exited the session stack you had all of the Kerberos > and AFS stuff set up properly. I'm open to other ideas! But recall > that for us keyrings are a hard requirement. > > --Ken -- ******************************** David William Botsch Programmer/Analyst @CornellCNF bot...@cnf.cornell.edu ******************************** _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info