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.
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 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.
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.
Best wishes,
Christian
On 10/13/25 02:34, Jeffrey E Altman wrote:
On 10/12/2025 7:56 PM, Jeffrey E Altman wrote:
Becoming 'root' via sudo is one of the cases where you do want a PAG
to be acquired. Do you have a "session required pam_afs_session.so"
rule specified in each of the /etc/pam.d/sudo* configuration files?
I believe what is necessary is to add
session optional pam_afs_session.so notokens
to /etc/pam.d/sudo
Jeffrey Altman
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
