[OpenAFS] home on afs woes

[Jeffrey Hutzelman]

On Wednesday, January 04, 2006 02:55:19 PM -0800 Russ Allbery 
<rra@stanford.edu> 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