pam-auth-update Account-Type should be "Additional"

[Ray Link]

Currently, libpam-ldap provides a pam-auth-update stub that inserts pam_ldap into the authorization stack as Account-Type: Primary.

Unfortunately, this means that, should pam_unix (also Account-Type: Primary) succeed, pam_ldap will never be checked. It also means that anything wishing to conflict with pam_ldap by providing a stub with "Conflicts: ldap" and a properly-behaving "Account-Type: Additional" will not actually end up conflicting with the misplaced pam_ldap.

In general, while the "Auth" stack is permissive (once one succeeds, the user has proven their identity, there's no sense in running additional authentication checks, so you skip checking the rest and just let the user through) and are thus perfectly suited to be Auth-Type: Primary, the "Account" (authorization) stack is essentially a gauntlet of potential denials, meaning every single PAM module should be run (Account-Type: Additional) to check for an authorization failure, even if others have already succeeded.

See Debian bugs #583483, #583492, and especially response #20 to Debian bug #610888.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583483
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583492
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610888#20

[Russ Allbery (rra-debian)]

This analysis looks right to me, and I think may run deeper than just this one module. If every account module should be additional and not primary, I think that points to an error in the data model or interpretation of the data model, rather than in individual PAM configurations. And viewing the account stack as a guantlet of denials where one should therefore not skip modules makes sense to me.

Modules doing account checks for which the auth check never ran and which therefore cannot do anything meaningful (not the case for pam_ldap, where the auth and account checks are unrelated, but the case for things like pam-krb5) should return PAM_IGNORE on account if they're not meaningful. And indeed pam-krb5 already does.

Adding libpam-runtime to get the opinion of the pam-auth-update author.

[Russ Allbery (rra-debian)]

Ah, in fact, I see comment #20 mentioned above is from Steve.

Steve, when would you ever want to have an account type of Primary given those semantics? Shouldn't Primary just be treated the same as Additional for the account stack?