libpam-afs-session gives user membership in nonexistant group

[Todd Taft]

Binary package hint: libpam-afs-session

Using libpam-afs-session 1.7-2 on x86_64 version of Ubuntu 10.04.1

When I have this module in my PAM stack and I authenticate as a user with an AFS identity (and get a token), I get added to a group that doesn't exist, as reported by the id and groups commands:

$ id
uid=648(taft) gid=200(bioinf) groups=200(bioinf),2693(csbio),2694(csbioadm),1103439836
$ groups
bioinf csbio csbioadm groups: cannot find name for group ID 1103439836
1103439836

1103439836 is not a group (or gid number of a group) that is defined anywhere on my system. If I comment out pam_afs_session.so from the common pam stack files, I don't see this behavior.

Since the default Ubuntu /etc/bash.bashrc file runs the groups command, every time that I login as a user with an AFS identity, I get the above error message (groups: cannot find name for group ID 1103439836) before my first shell prompt.

Note that the number of the non-existent group is not always the same.

The files in /etc/pam.d on this system are:

common-account

account [success=2 new_authtok_reqd=done default=ignore] pam_unix.so
account [success=1 default=ignore] pam_ldap.so
account requisite pam_deny.so
account required pam_permit.so
account required pam_krb5.so minimum_uid=200

common-auth

auth [success=3 default=ignore] pam_krb5.so minimum_uid=200
auth [success=2 default=ignore] pam_unix.so nullok_secure try_first_pass
auth [success=1 default=ignore] pam_ldap.so use_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
auth optional pam_afs_session.so
auth optional pam_cap.so

common-password

password requisite pam_cracklib.so retry=3 minlen=8 difok=3
password requisite pam_krb5.so minimum_uid=200 try_first_pass use_authtok
password [success=2 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512
password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass
password requisite pam_deny.so
password required pam_permit.so
password optional pam_gnome_keyring.so

common-session

session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session optional pam_krb5.so minimum_uid=200
session required pam_unix.so
session optional pam_ldap.so
session optional pam_afs_session.so
session optional pam_ck_connector.so nox11

common-session-noninteractive

session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session optional pam_krb5.so minimum_uid=200
session required pam_unix.so
session optional pam_ldap.so
session optional pam_afs_session.so

[Russ Allbery (rra-debian)]

Todd Taft <email address hidden> writes:

> When I have this module in my PAM stack and I authenticate as a user
> with an AFS identity (and get a token), I get added to a group that
> doesn't exist, as reported by the id and groups commands:

Yes, that's the group that tracks the AFS PAG.

> Since the default Ubuntu /etc/bash.bashrc file runs the groups command,
> every time that I login as a user with an AFS identity, I get the above
> error message (groups: cannot find name for group ID 1103439836) before
> my first shell prompt.

Yup.

AFS has always worked this way. The PAG group can in theory be dropped on
kernels where keyrings are used to track the PAG, although there are
AFS-aware tools that will be confused about the PAG status if that group
is not present. I think that's being looked at for the next major version
of AFS.

But this isn't a bug in pam-afs-session; indeed, for the current version
of AFS, it would be a bug if it *didn't* add that group.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>