Dante: A Socks server and client implementation [PSARC/2008/714 timeout 11/25/2008]

[James Carlson]

Jyri Virkki writes:
> 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.

Three points about that:

  The ARC is a body that has many members.  It's the members who
  review things, so "required by ARC" is a bit of a wobbly concept.
  As with any other review, you'll get slightly different answers
  depending on the question asked and the people involved in the
  review.

  My reading of 2002/053 doesn't suggest at all that the ARC
  "required" PAM for that project.  In fact, the record shows that we
  had the same discussion about PAM being used (optionally, as one of
  three realms) even though the user doesn't actually log into
  Solaris.  (And going back to 1995/269, it's clear that the focus was
  system login, and not network application 'user' management.)

  Further reading suggests that the "Solaris realm" concept came from
  the project team, not from the ARC.  I can find no record of a PAM
  discussion in the minutes.

In any event, I think the original concern was about having excessive
privileges for a network-facing program.  (It may also have been about
the third-party nature of the source, but I don't actually care about
that issue.)

The point I was raising was that we're lacking in architecture here.
It should be possible to administer identities of users used for
application purposes without necessarily tying those users to UNIX
UIDs.  It's the lack of administration that drives people to (ab)use
PAM as something other than a system login mechanism.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677