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