On 10/13/2025 5:11 PM, Christian wrote:
Hi all,
I did some more research on the behavior of sudo -i on debian trixie
when nopag is set in /etc/krb5.conf.
After sudo -i is run by a user having tickets and tokens, the debug
messages from pam_afs_session tell me that it is being run by the PAM
stack and acquires tokens because the KRB5CCNAME environment variable
is passed to root when sudo -i is run. The token itself is not
"passed" (that would cross user boundaries); it is acquired by root
based on the "passed" environment variable KRB5CCNAME and because root
can read the user's credential cache. This behavior could presumably
be changed by reconfiguring the way sudo passes this environment
variable.
This is why I suggested that the "notokens" option be configured for
pam_afs_session.so in /etc/pam.d/sudo.
The "root" session must have a PAG but I do not believe that "root"
should automatically acquire tokens from the user's identity.
What is strange is that when I exit the shell opened with sudo, the
tokens are lost also for the original user, even if I did not destroy
them as root. Debug log below - could these calls affect the original
user's environment?
sudo: pam_unix(sudo-i:session): session closed for user root
sudo: pam_afs_session(sudo-i:session): pam_sm_close_session: entry
(silent)
sudo: pam_afs_session(sudo-i:session): destroying tokens
pam_afs_session(sudo-i:session): pam_sm_close_session: exit (success)
sudo: pam_afs_session(sudo-i:setcred): pam_sm_setcred: entry
(delete|silent)
pam_afs_session(sudo-i:setcred): destroying tokens
pam_afs_session(sudo-i:setcred): pam_sm_setcred: exit (success)
The above is when there is no PAG for "root" or for the sudo caller?
If not, then it matters which uid is effective when the second
"destroying tokens" is logged.
The debian pam config for sudo -i is as follows (I am merging all the
included files into one sequence here):
session required pam_limits.so
auth [success=2 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=1 default=ignore] pam_unix.so nullok try_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
auth optional pam_afs_session.so
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
account requisite pam_deny.so
account required pam_permit.so
account required pam_krb5.so minimum_uid=1000
session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session optional pam_umask.so
session optional pam_krb5.so minimum_uid=1000
session required pam_unix.so
session optional pam_afs_session.so
session optional pam_systemd.so
I know that it is in principle possible to have different PAM configs
that keep PAGs for certain applications (such as ssh or sudo -i or
login), but disable them e.g. for gdm-password. But I like to keep the
decisions of my distribution in place as much as possible, and I would
not like to recommend to people in our institute with their
self-administered workstations to start fooling around with the PAM
stack.
There is an argument to be made that the Debian shipped configuration is
broken since PAGs can no longer be used for the desktop login.
The addition of the pam_afs_session.so Auth and Session settings are
performed by the Debian libpam_afs_session package.
https://packages.debian.org/trixie/libpam-afs-session
How about if we changed libpam-afs-session such that it reads
additional info from /etc/krb5.conf, such as:
[appdefaults]
get-pag-for = {
login = true
sshd = true
sudo-i = true
}
no-pag-for = {
some-other-service = true
}
The idea is that in case nopag IS NOT set, the no-pag-for list would
apply. In case noag IS set, get-pag-for would apply. That would
preserve the existing behavior.
Would such a modification make sense? Should not be too hard... I am
happy to look into it in case people find this idea useful... That
would allow us to configure whether or not to use PAGs on a per
service basis without having to fool around with the distribution's
PAM configuration.
AuriStorFS includes a pam_afs_session equivalent which does not permit
configuration to be specified via krb5.conf.
The option to read configuration from krb5.conf is not portable. It
depends upon the pam_afs_session build options, the version of Kerberos
it is linked against, and the operating system.
I would pursue updating the libpam_afs-session package.
Jeffrey Altman
