Comment 14 for bug 275169

On Wed, Jan 07, 2009 at 09:55:44PM -0000, Russ Allbery wrote:
> > 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.

> I never liked pam_deny for the common case where there's at least one
> other module that's required. It works when you generate the
> configuration with the end token, but if people then fiddle with it by
> hand, they have to keep all the numbers aligned.

Well, if people fiddle with it by hand they're going to have annoying
debconf prompts on upgrades, too. My goal is certainly to get this working
well enough that they have no cause to fiddle.

The pam_deny is useful because it simplifies the writing of the config
snippets; modules don't in general have to know they're the last module in
the stack and be handled differently, so it's less error-prone from that end
than having to juggle up to four different variant lines for the same module
and PAM type.

Anyway, I think I figured out a way to plug pam_krb5 into the stack the way
we want, without having to extend the syntax - given that we explicitly want
(pam_unix or pam_ldap) *and* pam_krb5, that's already doable by making
pam_krb5 'additional' for the 'account' type.

Doing that gives me:

account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
account requisite pam_deny.so
account required pam_permit.so
account required pam_krb5.so minimum_uid=1000

which should be more or less equivalent, in spite of the differing module
order.

> Well, I'm currently uploading libpam-krb5 packages to experimental anyway
> to avoid the freeze. What's in experimental will go into unstable after
> the lenny release.

Ah. I don't have any plans to upload pam to experimental in the meantime,
though, so it would just have an unsatisfiable dependency. :)

> When adding the session block, note:

> If you use a more complex configuration with the Linux PAM [] syntax for
> the session and account groups, note that pam_krb5 returns a status of
> ignore, not success, if the user didn't log on with Kerberos. You may
> need to handle that explicitly with ignore=ignore in your action list.

> If you do [success=end default=die] or something equivalent, ignore will
> cause failure. You *should* be able to do:

> [success=end ignore=ignore default=bad]

Ok. I don't think there's a need for anything more than 'optional' here,
really.

Next take at the config:

Name: Kerberos authentication
Default: yes
Priority: 704
Auth-Type: Primary
Auth:
 [success=end default=ignore] pam_krb5.so minimum_uid=1000 try_first_pass
Auth-Initial:
 [success=end default=ignore] pam_krb5.so minimum_uid=1000
Account-Type: Additional
Account:
 required pam_krb5.so minimum_uid=1000
Password-Type: Primary
Password:
 requisite pam_krb5.so use_authtok try_first_pass minimum_uid=1000
Password-Initial:
 requisite pam_krb5.so minimum_uid=1000
Session-Type: Additional
Session:
 optional pam_krb5.so minimum_uid=1000

Works For Me - if someone else can also confirm that this works, I'll go
ahead and roll it up for jaunty.

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