[OpenAFS] How to replace pam_krb5 on RHEL 8 systems

[Dave Botsch]

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
botsch@cnf.cornell.edu
********************************