Steve Langasek <steve.langa...@canonical.com> 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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- no kerberos support for pam-auth-update? https://bugs.launchpad.net/bugs/275169 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
