Nicolas Williams schrieb:
> 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 :)
>
Well, SRSS doesn't do it from any install-time scripts but from a
transient auto-configuration service atm, but the main point really is
that it has to be done.
>> 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.
>
Well, add-on software should probably install its snippets into /opt -
and then must use full pathes to reference their bits. Things may get
ugly when installing into /usr is required (may prevent a
local-zone-only install, ..).
Modifying user_attr isn't really an option for something that should
apply to all users (in the normal case). I don't really see how
prof_attr enters the picture here, but policy.conf (or an eventual
host_attr(4)) also is a treacherous thing to modify. The difficulty
still remains that these changes should not clobber existing site-policy
changes, but augment the existing configuration - whatever it is.
And what to do when the *_attr databases reside in a centralized place
where local admins may have no write access?
> 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.
>
Any snippets for 'enriched' configuration provided by ISVs should
probably include any snippets whose place they take. But there still
must be one place where the switch is thrown - either replacing an
existing item or adding a new one. If that is the place that is also
used by customers to do their customization, then adding an item
in-place makes it easier for customers to see what is going on when they
maintain their policy than replacing the customers item, so that they
must chase links to find where their customization has gone.
> 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.
>
It should be recommended to make references to modules we ship through
our snippets, unless the policies we ship are insufficient.
But IMHO the best place to add extra functionality for certain (existing
or new) services (whether pam_dial_auth, pam_kiosk or
pam_snippet_for_sunray_integration) is at the level of the basic service
policy definitions - pam.conf or pam.d/$service. Adding extra
indirections as hooks for any possible customization leads to a
structure that noone understands any more - and where I'm still not
convinced that it solves all upgrade scenarios.
>> 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.
>
It is the product configuration tool that is the problem, whether it
runs automated or by manual invocation. Generally the feedback we get is
that installing and configuring requires too many steps already.
Requiring another manual configuration step would be seen as a step
backwards. And admins that normally don't modify their PAM configuration
themselves shouldn't be exposed to how we make our functionality work
(at that level) needlessly.
- J?rg
--
Joerg Barfurth phone: +49 40 23646662 / x66662
Software Engineer mailto:joerg.barfurth at sun.com
Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/
Thin Client Software http://www.sun.com/software/sunray/
Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/
