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 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.

-- 
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

Reply via email to