On Thu, Oct 09, 2008 at 05:49:39PM +0200, Joerg Barfurth wrote: > 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, ..).
Where the snippets go is interesting but irrelevant. We've talked about /etc/security/pam, for example. Whatever it is, we can see to it that there is a place where they go. (And they can go anywhere anyways since absolute paths are allowed.) > 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 Users have profiles, either granted explicitly through their user_attr(4) entry or through PROFS_GRANTED in policy.conf(4). > 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. So modifying prof_attr(4)/policy.conf(4) is harder than modifying pam.conf(4)? And building tools that make it easy to set system policy on system-wide, per-user, per-service, per-whatever basis is harder than building pam.conf(4) editing scripts? I don't buy it. > And what to do when the *_attr databases reside in a centralized place > where local admins may have no write access? Someone must have access. Also, that's what nsswitch.conf(4) is for. > >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. Yes, it does, and we're trying to cut those down and cut the maintenance burdern of pam.conf down while reducing the risk of nasty surprises. Perhaps that's too ambitious. > 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. I don't see what manual configuration step we're talking about here. (Sure, there's no tool maintain policy.conf(4), but that's easy to build.) Nico --
