On Thu, Oct 09, 2008 at 12:29:03PM +0200, Joerg Barfurth wrote:
> An example of this third type is Sun Ray Server Software, which is a
> layered product from within Sun, but in the same situation as a
> third-party ISV product would be. SRSS today applies the following kinds
> of changes to PAM configuration:
> a) Add its own modules to existing system service stacks, honoring
> existing customer policy.
> b) Create new service stacks, that derive from an existing system
> service stack (honoring customer policy) and add some extra modules.
> c) Create new, customizable service stacks with a default configuration
>
> (And yes: maintaining the pam.conf-munging code for this is not fun)
It is not, indeed.
> All of this customization should be applied (effectively) when the
> product is installed and undone when the product is uninstalled.
I'm not so sure. We ship krb5 bits by default, but you must run kclient
for them to be referenced from pam.conf. (Well, sortof. The pam.conf
entries for k* are there from the get go, IIRC.)
It's one thing to install software and another to configure it.
But that's a distinction without a difference from the p.o.v. of
pam.conf munging: it sill has to be done. (Oh, I suppose CAS avoidance
is good, but let's not pick nits :)
> How does the installer (or configuration tool) of some ISV or add-on
> software (rather than any 'someone') add a module to the authentication
> stack of all (or multiple) services? Obviously a change can apply to the
> current host only, as the software may not be present on other machines.
They'd add a pam.conf snippet to /usr/lib/security and then you'd select
it via a user_attr(4) or prof_att(4) modification.
The problem then becomes: what if we wanted to do another revamp like
the pam_unix.so.1 -> pam_unix_{auth, cred, account, password,
session}.so.1 split? E.g., what if we wanted to do the same for
pam_krb5, say?
We could make the necessary changes to our pam.conf snippets, but not to
the customer's.
Which is what I meant when I wrote that I was concerned about painting
ourselves into a corner.
We could try to avoid that by providing a include hook approach to
customization of pam.conf snippets that we ship, but, that may not avoid
the corner completely and is somewhat ugly.
> Requiring modification of host_attr/policy.conf works for policy
> customization by administrators. It doesn't work for (automated)
> addition of enriched functionality or new services by add-on software.
Arguably third-party/layered products should just install their pam.conf
snippets and let the sysadmin enable them by either changing system
policy or by running a product configuration tool that does it for them.
Nico
--
