--On Tuesday, October 07, 2008 02:55:20 PM -0500 Nicolas Williams <Nicolas.Williams at sun.com> wrote:
> On Tue, Oct 07, 2008 at 03:40:10PM -0400, Jeffrey Hutzelman wrote: >> --On Tuesday, October 07, 2008 07:52:49 PM +0200 Bart Blanquart >> <Bart.Blanquart at Sun.COM> wrote: >> >> > Editing pam.conf or any of the files we ship in /usr/lib/security is >> > not supported, and upgrading/patching/... will either overwrite them or >> > complain (whatever the packaging system does in such cases), but it >> > won't merge or modify the file contents. >> >> In other words, if I want to do something site-specific, I can no longer >> do it by shipping out a new file, now I have to edit some database on >> every machine. _PLEASE_ stop doing that! > > The alternative is maintaining complex and *brittle* pam.conf editing > programs. We've had a lot of trouble with those. > > Worse, we consider pam.conf fair game and may not preserve your > customizations on minor releases. We're talking about fixing that > problem. > > I agree that for Solaris 10 update releases we should not follow this > approach, but for OpenSolaris I believe we must. > > And no, you don't have to edit a database, at least not for the files > backend. You may have to edit /etc/security/policy.conf(4), but only > once. And even better, we may provide better interfaces for PAM > configuration than $EDITOR (kclient(1M) already does, imagine us > extending that into a single, simple utility). The thing is, there is no better interface for me than $EDITOR, because I not only edit configuration somewhere other than the machine where the policy will apply; I probably don't even edit it on a Solaris machine these days. And the important thing to us is not that it works on pick-your-favorite-platform, but that I can produce a file expressing the policy I want, check it in to a CVS repository into AFS, copy it into the repository on our distribution machine, and then SUP it out to every machine in our facility (modulo staging). As long as I can do that, I'm happy. I think it's great to add bells and whistles so that joe sysadmin with one machine doesn't have to learn how to hand-edit complex config files and risk having things break when he upgrades. That is, it's great until not having to edit pam.conf becomes not being _able_ to edit pam.conf, and then it makes my life hell, because I don't have one machine, I don't configure machines manually, and I could care less about what breaks upgrading from Solaris 10 to 11 or whatever, because we _never_ do upgrades like that. > Because we're an open community and responsive we'll look at integrating > all custom policies that use only modules shipped with Solaris. We'll > also look at integrating FOSS PAM modules. So that for most of you > there should not ever be a PAM configuration issue on upgrade. And that's great for people who are using modules that ship with Solaris. But since no module that ships with Solaris implements our peculiar policies, and I'm not interested in spending time packaging, distributing, and maintaining something no one else cares about, it doesn't help me. And really, it doesn't count as supporting site-specific policy if the only way to be able to use your policy is to get it accepted upstream. -- Jeff
