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

[Richard L. Hamilton]

> Gary Winiger writes:
> > 	That said, one of the exported interfaces for all
> PAM applications
> > 	is the service name.  Perhaps I missed it in the
> exported interfaces.
> > 	Stability should likely be no lower than
> Uncommitted.  The service
> 
> Agreed; that's missing.  Looking at the code, that's
> "sockd" by
> default and can be overridden in the configuration
> file by using:
> 
>   pamservicename: new-name-here
> Furthermore, a project could create a PAM service
> e module just
> > 	to handle socks username/password authentication
> (and account
> > 	management) that didn't need to be tied to the
> hosts passwd(4) and
> > 	shadow(4) databases -- that may require no
> privilege.
> 
> Yes, a future project could do that, but I think
> doing it would
> actually drain a good part of the usefulness of PAM,
> at least for this
> project.
> 
> The problem is that administering users (and
> passwords) in a
> service-specific way scales poorly and is hard to
> manage.  Even if
> it's not "clean," many administrators would rather
> have a central
> registry for all users authenticated by the system
> for all
> applications, so that when a user is added or
> removed, they don't have
> to hunt down all the places where this data is
> squirrelled away.
> 
> Having per-service files greatly complicates matters,
> and virtually
> guarantees that something will be missed when changes
> are needed.

Which implies an opportunity for a way to use global name services
(LDAP, NIS, ...) to provide for alternative views of the available
account information based perhaps on a (service, host, domain) tuple.

That would provide global control, but specialized behavior, such that
services facing a hostile environment could be restricted to only authenticate
accounts that have been designated for use by that service on that system.
Maybe even more is needed, such that what a service could see could
depend on which interface the the request was received, although I don't
see a mechanism that could be extended to achieve that.

Again, not this case of course, but perhaps a potentially wide-spread
problem worth further consideration.
-- 
This message posted from opensolaris.org