On Tue, Oct 07, 2008 at 07:52:49PM +0200, Bart Blanquart wrote:
> > OTOH, this falls down if you end up combining pam_user_policy with
> > pam_authorized and expect to have different profiles for pam_authorized
> > according to {PAM_SERVICE, PAM conf file where pam_authorized invoked},
> > as we don't track the latter.
> >
> > I'm not sure how important that is. But it'd be good to have an answer
> > for that, and at the moment I don't.
>
> Now, the goal is to avoid the need to deal with modified pam.conf or
> equivalent files when upgrading a system (or patching or similar).
>
> The easiest way to go about that seems fairly simple:
>
> - we ship a pam.conf that contains a binding entry with pam_user_policy
> and a second binding entry with pam_system_policy and nothing more
Or, with only pam_user_policy and then the stock configurations
referenced by each user's [or user's profile's] pam_policy attribute
includes a suitable pam_authorized module invocation.
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.
I'm not sure that this is really necessary. I think it will almost
certainly suffice at first to have pam_authorized look for a single
variable in policy.conf(4), expand tokens (like %S -> PAM_SERVICE), and
use the result.
Nico
--
