[OpenAFS] home on afs woes

[Sergio Gelato]

* 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 ?

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.)

> 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.

> > That seems to call for a host.hostname entry in PTS and a way for sshd
> > etc. to obtain an AFS token for that, discarding it (e.g. by changing
> > PAGs) before control is handed to the user... OK, I see that Jeffrey
> > Altman has beaten me by a few minutes.
> 
> Yeah, Jeff's idea is an interesting one.  It's a lot of PTS IDs, but I
> guess that isn't really a scarce commodity.

Not much scarcer than IPv4 addresses.

The case of the unprivileged screen saver trying to krb5_kuserok() may
be tricky, though, especially if the session's original token has expired.
This may be a valid use for a module option to relax the krb5_kuserok()
check; other such uses have been discussed in the past, e.g. for
POP toasters with virtual accounts. (Which reminds me that Courier's
authlib also skips, or used to skip, the account stack.)