On Thursday, January 05, 2006 01:05:19 AM +0100 Sergio Gelato
<[EMAIL PROTECTED]> wrote:
* Russ Allbery [2006-01-04 14:55:19 -0800]:
Sergio Gelato <[EMAIL PROTECTED]> 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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
