Gary Winiger wrote: >> Nicolas Williams wrote: >> >>> On Tue, Jul 22, 2008 at 04:07:16PM -0700, Gary Winiger wrote: >>> >>>> Hummm, looking at the architecture of passwd(1), it only >>>> supports 2 repositories. I suspect this is left over from some >>>> >>> The question is: Is this architecture? Where is it written that >>> passwd(1) has/must have this limitation? If it isn't a stated >>> limitation then we'll simply fix this bug, otherwise we'll simply change >>> that limitation. >>> >>> passwd(1) says: >>> >>> When a user has a password stored in one of the name ser- >>> vices as well as a local files entry, the passwd command >>> updates both. It is possible to have different passwords in >>> the name service and local files entry. Use passwd -r to >>> change a specific password repository. >>> >>> I don't think that implies a limit of two name service backends for the >>> passwd database. >>> >> passwd(1) also says: >> > > IMO, there is still an incomplete specification here. The > getxby stuff is clear enough from the discussion, but IMO, > not from the man page changes. IMO, that's a NIT that can be > worked off line. > It's the putxby stuff as privately implemented since SunOS 2.x/3.x > when NIS (nee yp) was added to passwd that has been brought > forward to/through the name service switch that is more the > architecture that I'm finding a need for more detail. Indeed > not all architecture is captured in man pages. And without > doing a good bit of archaeology on passwd/passwdutil, name > services (probably also nisplus) ARC cases, I can't say if the > two backends architecture was ever formally presented. >
The nsswitch is capable of supporting multiple backends architecture-wise. However in the past we have told customers (and is also mentioned in nsswitch.conf manpage) that we do not support mixing nis, nisplus and ldap name services on a single box. This is because we have not tested these configurations and we do not provide any tools to the customer to install/configure their systems in such manner. (For e.g. ldapclient does not allow the user to keep their existing nis/nisplus configuration alongwith ldap. They have to manually move files which is not supported). Therefore all that remains and which were tested are the single and two-backends (where one must be files) configurations. Removing this restriction will require testing configurations involving multilple non-ad backends and is beyond the scope of this case. Therefore for this case, I suggest we notify users through nsswitch.conf(4) and passwd(1) manpages that adding "ad" to the existing valid configurations is supported and that "ad" will be skipped during password updates via passwd(1). --Baban > I can say it is present in the code and has been explicitly > called out for some time. IMO, that may not make it formal > architecture, but it also does not make it a bug. > Back to my original concern: Is this case modifying the passwd: > (and any other database:) architecture to allow for more than > two name services? If so, will ad be explicitly worked around > in the passwd(1) implementation (including the putxbyy private > implementations and interactions with nsswitch)? How will > such be documented for the admin/user? > Please don't interpret this as opposing adding nss_ad, or > changing the nsswitch or passwd/passwdutil/putxbyy architectures. > It's that these are security relevant and don't seem to me > well enough specified in the case materials. > > Gary.. > >> .... >> If all requirements are met, by default, the passwd command >> consults /etc/nsswitch.conf to determine in which reposi- >> tories to perform password update. It searches the passwd >> and passwd_compat entries. The sources (repositories) asso- >> ciated with these entries are updated. However, the password >> update configurations supported are limited to the following >> cases. Failure to comply with the configurations prevents >> users from logging onto the system. The password update con- >> figurations are: >> >> o passwd: files >> >> o passwd: files ldap >> > _______________________________________________ > sparks-discuss mailing list > sparks-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/sparks-discuss >
