[OpenAFS] home on afs woes

[Jeffrey Hutzelman]

On Thursday, January 05, 2006 01:05:19 AM +0100 Sergio Gelato 
<Sergio.Gelato@astro.su.se> wrote:

> * Russ Allbery [2006-01-04 14:55:19 -0800]:
>> Sergio Gelato <Sergio.Gelato@astro.su.se> writes:
>> > 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.
>
> My understanding is that in the Kerberos case this is counterproductive:
> a principal with an expired password will only be able to get a ticket
> for the password-changing service, which the PAM application isn't in a
> position to verify. Surely you don't want to make the authentication
> succeed on KDC_ERR_KEY_EXPIRED ?

Actually, for a full-service application that supports password-changing, 
you need to do exactly that.  The authentication step succeeds, and the 
password-expired error is returned during account management, which tells 
the application to try changing it.

For applications that don't support account management, you need to return 
an error in the authentication phase, and the user simply will not be able 
to use that application until they have corrected the expired password 
problem.

I agree, this is suboptimal.  Password expiration (as opposed to account 
expiration) is an authentication problem, and should be handled at the 
authentication stage.  However, that's not now PAM works.


> Screen savers clearly ought to call the account stack; it should be the
> system administrator's job to configure that sensibly, according to site
> policy. Maybe it's OK to use pam_permit, maybe not. And I see no reason
> why a screen saver couldn't prompt the user for a password change.
> (Well, not for a Kerberos password change anyway; I suppose that some
> other authentication systems may require root privileges in order to
> change a password and the screen saver may be running unprivileged.)

I'm afraid that is not "clearly" the right behavior.

A screen saver is not making access decisions.  It doesn't grant or deny 
access to the machine, and it's not responsible for deciding whether any 
given user gets to start a session.  Those decisions were made when the 
user logged in.  What the screen locker is doing is a considerably simpler 
operation on behalf of the _user_, not the system; specifically, it is 
preventing the terminal from being used without successful authentication.

Since the screen locker is not making access decisions on behalf of the 
system, it's not necessary for it to call account management, and in fact 
inappropriate to refuse to unlock on the basis of an account management 
issue.  I'm not going to say "clearly", because there is plenty of room for 
argument here.  I will point out that this philosophy seems to be 
consistent with the behavior of existing PAM libraries and applications, 
and that this list is not the most effective place to try to convince the 
PAM community to adopt a new approach.


Sadly, this leaves is in a position where a screen locker can't handle a 
password change, because to detect that one is needed it has to call 
pam_acct_mgmt, and then it would have to decide what to do about results 
other than success or password-expired.  Failing on all such results isn't 
the right thing to do, but neither is ignoring them.


>> Don't ask me; I don't write the applications, I just try to hack PAM
>> modules to work with them.
>
> That's an unfortunate division of labour.

Actually, it's highly desirable to have a modular architecture in which 
applications, PAM modules, and the PAM framework can be and are maintained 
by indpenedent entities.  The unfortunate part is that the semantics of PAM 
operations are not as well-defined as they could be, and even those parts 
that are well-defined aren't as well-documented as they could be.  Of 
course, it also doesn't help that any number of PAM application authors 
have managed to completely ignore even what documentation does exist.


-- Jeff