Mike Smith wrote:
>
> > > > > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com
> > > > >
> > > > > Horrible idea.
> > > > >
> > > >
> > > > suggestions?
> > >
> > > Use PAM.
> >
> > PAM isn't going to cut it. This is outside of its realm. Things like ps,
> > top, ls, chown, chmod, lpr, rcmd, who, w, (the list goes on) need to be able
> > to pull 'passwd' entries from the LDAP server, and unless we PAM all of
> > those
> > (I think that is a very bad idea), then a person will be able to login but
> > will be dead in the water without a UID <->Username mapping.
>
> The Linux-PAM folks solved this with their 'libpwdb', which basically
> provides a transport-neutral interface to the whole uid:userdata
> mapping. Unfortunately, their implementation _reeks_, so nobody has
> touched it yet.
>
> This is, however, how I think we should be going.
100% agreement here. This needs to be implemented such that the administrator
configures the box to use local files, or NIS, or LDAP, or whatever as the
source of username information, and both login(1) and ls(1) use the information
as appropriate. For ls(1) and friends, this means implementing getpwuid(3)
(and
getgrgid(3)) so they "just work."
The implementation details are as unimportant as ever: they have to work
and be maintainable. Following prior art remains a good idea; the Solaris
"name service switch" implementation is a good starting point to consider.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
http://softweyr.com/ w...@softweyr.com
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
