On 07 Oct 2008, at 23:54, Nicolas Williams wrote: > On Tue, Oct 07, 2008 at 11:53:46PM +0200, Bart Blanquart wrote: >> >> On 07 Oct 2008, at 21:16, Nicolas Williams wrote: >>> But I took Darren's point to go a bit farther: that sysadmins should >>> have control over what policy each pam_authorized module invocation >>> referenced in the various pam.conf snippets should use, on a >>> per-pam.conf snippet basis. >>> >>> I think there's a simple way to accomplish that which still makes it >>> possible for us to have non-editable PAM configurations: >>> >>> - Let pam_authorized take a module argument naming the suffix of a >>> policy.conf variable. >>> >>> I.e., "pam_authorized.so.1 FOO" -> pam_authorized uses >>> PAM_AUTHZ_FOO >>> (or whatever the prefix is, suffixed by "_FOO"). >>> >>> - If that can't be found in policy.conf, then fallback on the >>> default >>> policy.conf variable name. >> >> Why would this be better than having pam_authorized take a module >> argument that points to a policy profile, and falling back to some >> default (that could come from policy.conf or better yet host_attr)? > > Because you'd not ever have to change any PAM config to set that.
I think I'm missing something here: "take a module argument naming the suffix of a policy.conf variable" means that the module gets an argument, which is specified in a pam.conf snippet somewhere. If we ship our snippets with such a variable there I would rather we put a proper "policy=" option in place, and ship empty profiles that can be modified locally, as that offers a clean configuration option for other people writing snippets where they might want to use pam_authorized. If we don't ship our snippets with such a variable in place people would either need to edit the snippets (bad) or copy them and then edit them (not so bad, as those won't clash with our stuff should we feel the need to change things later in a snippet). Bart
