Joep Vesseur wrote:
> On 11/19/08 06:24, Jyri Virkki wrote:
>
>> James Carlson wrote:
>>
>>> I agree that using PAM is a bit architecturally suspicious, as we're
>>> not authenticating users for the purpose of logging them into the
>>> system, but it has operational advantages, including:
>>>
>> For some historical trivia, PSARC/2002/053 for iPlanet Application
>> Server 7 required the app server to add a module to support
>> authentication via PAM. So that use case has been not only accepted
>> but actually required by ARC in the past.
>>
>
> Personally I wasn't worried that PAM was used to authenticate users; after all
> it is a perfect (well, perfect.. :) way to modularize access control
> policies. What I was surprised about is that PAM was being used to
> authenticate users against the normal system repositories, i.e. the ones
> containing actual system-login credentials. Personally, I'm not too fond of
> internet-facing systems processing all sorts of untrusted data having access
> to login-credentials.
>
> As Jim pointed out, there is a maintenance gain compared to setting up and
> maintaining separate databases, but from where I'm standing that doesn't
> compensate for the increased security risk.
>
> All of this is not relevant to the case at hand though, as the model has been
> decided on by the upstream developers.
>
> Joep
>
This problem (one of multiple credential databases, and separation of
account namespaces, or at least credential details, into different
databases) sounds like one of the areas where we (Sun/Solaris) can
innovate. Right now there is a vacuum here, and so projects are faced
with either inventing their own, or using the system credentials.
The idea of using PAM infrastructure seems like a good one to me. But
designing a full framework that allows for multiple authentication dbs
is something that might not be trivial.
Of course, all that is not this case. But if this case were a full
case, a project to work on this seems like some advice we could give to
the PAC.
Perhaps we should derail so that we can offer this advice? (I'm on
sabbatical, so I won't derail. But I propose that someone else do so,
and we go right to a vote, since I don't think a full *review* is
required for this case.)
(Hmm... we've seen this before. Maybe ARC needs a better way to
communicate advice to PAC. Perhaps a way to provide an "opinion" on a
fast-track without actually derailing it?)
-- Garrett
