Joep Vesseur writes:
> If this were a review of an in-house developed piece of software, I'd strongly
> suggest to find alternatives (either run with just the privileges needed to
> validate passwords, or run with a different database, or delegate
> authenticating users to a sub-task that doesn't deal with forwarding packets
> like the main daemon does). I don't know how far we'd go for imported
> products; I guess it depends on what we want to build on top of this.
I think having a separate, generic authenticator daemon to run the PAM
functions on behalf of less-privileged programs (and thus isolating
the must-have-all-privileges-and-EUID-0 nature of PAM's access to
/etc/shadow to a single process) would be a nice addition to the
system. It sounds like a good project to me, but I don't think it's
this one. (If it is done here, then it'd be the sort of privilege
fork hack that you're describing, and I'd be less in favor of that
unless it's well maintained upstream.)
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:
- The administrator can modify pam.conf to insert locally useful
changes to the stack used with this daemon, and thus implement
local policy. No changes to the daemon required; cheap and
effective.
- Using the same user database as the rest of the system simplifies
administration. You don't need a separate set of tools to
administer SOCKS users, and, more importantly, when you remove a
user from the system, his SOCKS access goes away, too. Having
multiple databases (as you're recommending) increases the chances
of accidentally leaving an unwanted user ID hidden somewhere in
some obscure application's database, because we don't have a
global administration tool.
What we *really* need for these network services is a well-supported
AAA infrastructure. Too bad we don't have that.
> Note, however, that I'm not a PSARC member, just an interested lurker.
The point of the ARC is to get interested lurkers to comment on
relevant cases, so you're welcome here.
--
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
