On Wednesday, January 04, 2006 02:55:19 PM -0800 Russ Allbery
<[EMAIL PROTECTED]> wrote:
As far as the screensavers' not running the account stack, I'd be more
worried about what happens when a Kerberos password has just expired
than about krb5_kuserok() being skipped: after all, the initial login
must have run the account stack successfully.
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.
(The other pain in the ass are screen savers like xlockmore that also
don't call either pam_setcred or pam_open_session -- why are there two
APIs when most PAM modules appear to treat these as synonymous? -- which
means that they don't refresh Kerberos tickets and AFS tokens.)
Well, they shouldn't call pam_open_session, because they're not opening a
new session. 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.
-- Jeff
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
