Comment 10 for bug 275169

On Wed, Jan 07, 2009 at 06:38:24PM -0000, Russ Allbery wrote:
> Steve Langasek <email address hidden> writes:

> > For comparison, here's the /usr/share/pam-configs/krb5 I've been using
> > locally for testing:

> > Account-Type: Primary
> > Account:
> > [success=end new_authtok_reqd=done default=ignore] pam_krb5.so

> What does end do? It's not documented in the PAM manual. Is that
> equivalent to done?

This is not a PAM token, but a token that's rewritten by pam-auth-update
when generating /etc/pam.d/common-* from these files.

  https://wiki.ubuntu.com/PAMConfigFrameworkSpec

"end" means "jump to the end of this group of modules" - it's replaced by a
number once pam-auth-update knows how many modules there are, since this is
dynamic.

> I believe "done" would bypass all local account expiration checks, meaning
> that if an account were locally locked, they would still be able to log on
> via Kerberos, which is something the recommended configuration is careful
> not to do.

True. Perhaps this should be:

  Account:
     required pam_krb5.so minimum_uid=1000

However, then we run into trouble if pam_krb5 is the /last/ module in the
stack (i.e., the admin has chosen to disable pam_unix completely), because
the next line after this will then be:

   account requisite pam_deny.so

... which obviously isn't going to work.

So it looks like there's a need for a full range of
(Initial,Medial,Final,Isolate) semantics after all, and I'll have to add
that back into the spec and get it into the pam-auth-update implementation.

That'll push back the libpam-krb5 upload by a couple of days, at least.

> Is this something that should also be included in the Debian package?

Not until after lenny; unfortunately the development work for this only got
done after lenny had gone into freeze, so it wasn't appropriate to
completely reconfigure the PAM handling at that point.

> > BTW, I've never needed to use the pam_krb5 session module. As far as
> > I'm aware, that only exists as a workaround for services that don't call
> > pam_setcred() as expected. Do you know of specific cases where this is
> > needed in your environment?

> Is there any reason *not* to run it? As upstream maintainer, I would
> certainly recommend adding pam_krb5 to the session configuration. Under
> most circumstances, it's a no-op, but the module recognizes when it is,
> and there are applications that don't call setcred.

Ok - I have a slight aversion to enabling things that "should" be no-ops,
and I don't know of any PAM services in Debian or Ubuntu that fail to call
pam_setcred(); but if you recommend enabling this for compatibility, then we
can go that way.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>