[OpenAFS] home dir in afs, debian

[Christian]

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
> 
>