> 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
