On Wed, Oct 8, 2008 at 9:02 AM, Bart Blanquart <Bart.Blanquart at sun.com> wrote: > On 10/08/08 15:44, Mike Gerdts wrote: >> On Wed, Oct 8, 2008 at 8:21 AM, Bart Blanquart <Bart.Blanquart at sun.com> >> wrote: >>> When a system is upgraded pam.conf no longer contains much useful >>> besides some modules that include pam snippets. One such snippet might >>> be the local policy (i.e. pam.conf as it was before the upgrade, now >>> moved to /usr/lib/security/local_policy or so). >> >> Where can I find details on this move? When I search opensolaris.org >> for local_policy the only hits seem to be related to java. >> > > Well, there's no move -- there's only an idea describing how we could > get rid of having packaging tools poke at the contents of PAM > configuration files. It's been described in these threads (the > pam_authorized one and the PAM configuratio semantics one) as the need > to make it possible to no longer deal with things like i.pamconf in the > packaging system was raised. > > The bits that make it possible to conditionally include other files into > a PAM stack are described in > http://opensolaris.org/os/community/arc/caselog/2005/275/ (specifically > the pam_eval and pam_user_policy files). > > Note that that case doesn't deal with what I've described above, only > with some PAM features that would make such an approach possible.
I was asking because I was concerned that configuration files were being put into a directory that is commonly inherited by sparse zones. A read through pam_user_policy.man clarifies that only relative paths. I have a bit of concern that one of the examples suggests that custom entries would also exist in /usr/lib/security, but it is somewhat balanced by another example of putting it in /etc where it belongs. I suspect that in the long run it would be best for 2005/275 to say that /usr/lib/security is reserved for [Open]Solaris and that custom files that are placed there may be removed or replaced during patching or upgrade. This way a site that is ahead of Sun in having a new whatever.conf file in that directory doesn't get into trouble when Sun delivers whatever.conf. The one thing (there is probably another, but I can't think of it right now) I liked about CDE was the way it handled configuration files. Those in /usr/dt may get whacked by any patch or upgrade, but customized versions could be placed in /etc/dt. Such a mechanism (/usr/lib/security, /etc/site/security(?)) could be a good thing to make it unnecessary for sites to start doing active management of *_attr name services. I guess that's another thread that I should have been on 3 years ago. -- Mike Gerdts http://mgerdts.blogspot.com/
