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