Comment 15 for bug 275169

Steve Langasek <email address hidden> writes:

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

Yeah, that makes sense. I can see where it would help when you're
automatically generating the configuration.

> 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

That works. That should do exactly what you want.

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

session should be fine with optional. account should be required
(although in practice the authorization checks are also done in auth since
too many broken programs don't check the return status of account, so it
won't *really* matter).

> Next take at the config:

It looks good to me on visual inspection, although I don't have a system
on which to test.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>