On Tue, Oct 07, 2008 at 11:29:53PM +0200, Bart Blanquart wrote: > On 07 Oct 2008, at 23:03, Nicolas Williams wrote: > > Scriptable interfaces will be. We could make it so that just > > dropping in a PAM config file just NOT in /etc/pam.conf AND dropping > > in /etc/security.conf suffice. > > > > [But none of that removes risk from changes like the pam_unix.so.1 > > split up that was done for Solaris 10. So we might want to develop > > a more stable PAM customization interface. This is probably a > > subject for a separate thread.] > > The risk doesn't seem to be that big: as long as the old module is > still shipped nothing changes for an admin: they have dropped in their > own PAM configuration file and we're not touching it. If that > references modules we're no longer using then that's OK, really. > > If we remove modules the story changes, but then that's the stability > level we'd be at: we can't change the behaviour of any of the policy > files we ship in /usr/lib/security and we can't drop any modules (even > if we stop using them in our configs), but that doesn't seem to be too > much of a burden.
That's what happened when pam_unix.so.1 was split: the old one was removed. I agree that the PAM config snippets we deliver in /usr/lib/security have Committed semantics. That's clearly a good thing. The problem is that anyone writing their own such snippets won't be able to expect them to be stable, at least across minor releases of [Open]Solaris. The same applies to /etc/pam.conf itself today. ALTERNATIVELY we must do heroic PAM config upgrade scripting. Nico --
