[OpenAFS] home on afs woes
Wed, 04 Jan 2006 18:24:11 -0500
On Wednesday, January 04, 2006 02:55:19 PM -0800 Russ Allbery
>> 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.