Re: [OpenAFS] home dir in afs, debian
Dear Jan, thanks for the message. Setting nopag = true in the [appdefaults] section of /etc/krb5.conf appears to "fix" the gdm login. However, I am somewhat surprised (or maybe it is just a lack of understanding of sudo on my end) that if I log in as a user, and issue sudo -i, root still has tokens (presumably because pam_afs_session is called again, and because KRB5CCNAME is preserved?). If I now issue "unlog", tokens are gone, as expected. But then if I exit and return to "user", also "user"'s tokens are gone... Is that expected? Best wishes, Christian On 10/7/25 12:45, Jan Henrik Sylvester wrote: On 10/7/25 10:11 AM, Christian wrote: Tickets and tokens are there. But logging in to gnome via gdm3 fails. This list has had discussion on that topic before. In short, we used to have a systemd service to execute aklog in the systemd user session (after locating the correct Kerberos ticket cache), but we have given up on that approach and simply use the option nopag for pam_afs_session (in common-auth, common-session, and common-session-noninteractive). We have not had any trouble because of this (no token has vanished because one of multiple parallel SSH sessions has logged out or something like that). Best, Jan Henrik ___ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] home dir in afs, debian
On 10/12/2025 2:28 AM, Dirk Heinrichs wrote: Christian: However, I am somewhat surprised (or maybe it is just a lack of understanding of sudo on my end) that if I log in as a user, and issue sudo -i, root still has tokens This is exactly because of nopag. If 'root' inherits the tokens of the user that executed 'sudo', then something is broken. [jaltman@host]$ tokens Tokens held by the Cache Manager: Rxgk tokens for your-file-system.com [Expires Oct 13 13:46] User's (AFS ID 101) rxkad tokens for your-file-system.com [Expires Oct 13 13:46] --End of list-- [jaltman@hhost]$ sudo -i [sudo] password for jaltman: [root@host]# tokens Tokens held by the Cache Manager: --End of list-- When "nopag" is specified, the PAG id associated with the stored tokens is the local uid of the process executing 'aklog'. The local uid of 'root' is 0 which should not be the same of any normal user on the system. If the user who becomes 'root' obtains tokens as 'root', they will be associated with PAG ID 0. With an OpenAFS client on Linux its possible to list the PAGs for which tokens have been obtained. cat /proc/fs/openafs/unixusers If there are tokens assigned to UID/PAG 0, then those are the ones which will be active when any user executes 'sudo -i'. 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? Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] home dir in afs, debian
Am 13.10.25 um 23:11 schrieb Christian: The debian pam config for sudo -i is as follows (I am merging all the included files into one sequence here): auth [success=2 default=ignore] pam_krb5.so minimum_uid=1000 auth optional pam_afs_session.so Considering that AFS doesn't make any sense without Kerberos, I would suggest adding the same "minimum_uid" from pam_krb5 also to pam_afs_session. In fact, we use 1007 in our configuriations so that "local" users don't get automatic Kerberos and AFS tickets/tokens and only the users from LDAP. Our configuration looks like this (and works flawlessly with `sudo -i` and others): auth[..]pam_krb5.so minimum_uid=1007 authoptionalpam_afs_session.so minimum_uid=1007 nopag session optionalpam_krb5.so minimum_uid=1007 session optionalpam_afs_session.so minimum_uid=1007 nopag Greetings, Gaja
Re: [OpenAFS] home dir in afs, debian
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
Re: [OpenAFS] home dir in afs, debian
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
Re: [OpenAFS] home dir in afs, debian
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):
sessionrequired 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 requisitepam_deny.so
account required pam_permit.so
account required pam_krb5.so minimum_uid=1000
session [default=1] pam_permit.so
session requisitepam_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
Re: [OpenAFS] home dir in afs, debian
Christian: However, I am somewhat surprised (or maybe it is just a lack of understanding of sudo on my end) that if I log in as a user, and issue sudo -i, root still has tokens This is exactly because of nopag. HTH... Dirk -- Dirk Heinrichs Matrix-Adresse: @heini:chat.altum.de GPG Public Key: 80F1540E03A3968F3D79C382853C32C427B48049 Privacy Handbuch: https://www.privacy-handbuch.de OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [OpenAFS] home dir in afs, debian
On 10/7/25 10:11 AM, Christian wrote: Tickets and tokens are there. But logging in to gnome via gdm3 fails. This list has had discussion on that topic before. In short, we used to have a systemd service to execute aklog in the systemd user session (after locating the correct Kerberos ticket cache), but we have given up on that approach and simply use the option nopag for pam_afs_session (in common-auth, common-session, and common-session-noninteractive). We have not had any trouble because of this (no token has vanished because one of multiple parallel SSH sessions has logged out or something like that). Best, Jan Henrik ___ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
