Bart Blanquart 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.
Also we can't move it to /usr/lib/security/local_policy anyway because
/usr should be assumed to be read only and shared between zones (which
may require a different policy). It would need to be somewhere in /etc
or /var (the former being my preference).
In most other case on a upgrade of a complex subsystem we would put the
new file in place as .new and tell the admin (via the install/upgrade
log/event system) that they have worked todo.
The problem with some of the changes we have made to /etc/pam.conf in
the past (the break up of the monolithic pam_unix being a prime example)
is that if we don't make some changes to the old /etc/pam.conf then
nobody will be able to authenticate to login and make the manual merge
of .old and .new.
The combination of the already existing "include" keyword for pam.conf,
the addition of pam_user_policy (so that we can set a default policy of
unix for root by default) and the possible addition of /etc/pam.d/ (as
per LinuxPAM) greatly reduces the need for these types of modifications.
The other thing in our advantage for OpenSolaris 2008.05+ is that there
is no upgrade path from the Solaris releases where we had to do the
major mangling of /etc/pam.conf (S8 to S9 or S8 to S10 or S8 patches etc).
The priority tasks as I see it are:
1) Write unix,kerberos,ldap default policy files and ship
them in /usr/lib/security/ as templates
2) Deliver pam_user_policy and set the default for root to be
unix in user_attr(4) and the system wide default as unix in
policy.conf(4)
3) Introduce /etc/pam.d/<service> config syntax as per LinuxPAM
and make the default configuration be /etc/pam.d/<service>
having it take advantage of the files delivered in 1).
For upgrade to a system that delivers all 3 of those if the
/etc/pam.conf is one we previously delivered then we remove it. If it
isn't a file we delivered then we leave it in place. If we follow
LinuxPAM then the existence of an /etc/pam.conf disables looking at
/etc/pam.d/ so this leaves a safe situation.
I believe that once we have done that we will have resolved most of the
issues for upgrade and provided a nicer framework for delivering new and
changed authentication policies.
--
Darren J Moffat
