Jeffrey Hutzelman <[EMAIL PROTECTED]> writes: > Russ Allbery <[EMAIL PROTECTED]> wrote:
>> The screen savers that I've looked at actually explicitly don't call >> the account stack (or call it and ignore its return status) because >> they don't want to lock out users with expired accounts. >> >> Don't ask me; I don't write the applications, I just try to hack PAM >> modules to work with them. > This is the right behavior. pam_acct_mgmt() is about "account > management", not all-purpose authorization checks. In particular, it is > about deciding whether this account is allowed to log in at all, not > about whether a particular authenticated entity is allowed to access > that account. Such decisions are _expected_ to be made in > pam_authenticate. Ah, okay, that's good to know. That makes me think that the current Debian pam_krb5 implementation is correct here, and more correct than the previous version. > Well, they shouldn't call pam_open_session, because they're not opening > a new session. D'oh. Yes, of course. > There is an appropriate opcode to use with pam_setcred for this, and I > agree that applications that fail to do so are buggy. About all we can > do about it is submit patches and hope they clean up their act. I've submitted a Debian bug against xlockmore, at least. (And against xdm, which calls pam_setcred multiple times and discards the environment settings the last time it's called. And against OpenSSH, which calls pam_authenticate in a child process and doesn't preserve any pam_data across to the pam_setcred function.) -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
