[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: GDBM/DB password file support



Aleph One writes:
> On Thu, 10 Oct 1996, Andrew G. Morgan wrote:
> 
> > The problem is that Sun defined what PAM is supposed to do. It is basically
> > an authentication front end. Period. We might make a more general pluggable
> > API, but if we want to stick with the standard, I think we need a
> > (single) complimentary database library.
> > 
> > Applications require more than authentication. They may need to know the
> > home directory of a user they are granting a service to for example.
> > 
> > libpwdb is an attempt to provide a single yet flexible database API that
> > will address the needs of PAM and of applications at the same time..
> 
> I see. I would extend PAM but and do things the right way but I know you
> value sticking to the standard. If an application needs to know where the
> home directory of a user is then that is part of the authentication
> process. So what happens when say we want hesiod authentication? Do we
> make a PAM module? Do we make add it to libpwdb and add yet another
> protcol to pam_unix? Do we do both?

I've been lurking on this list for a while, so I might have missed
some context. I helped design PAM while working at SunSoft, and the 
reason PAM doesn't have any calls to do /etc/passwd-related stuff
is because there was already a well-defined interface for getting
password information: getpw*/getgw*. It was also already modular with
the name-service-switch (NSS) backend. The line does quickly blur when
you start dealing with updates, etc, so having another API to deal
with all the various /etc/passwd stuff is probably not a bad idea, we
just didn't think it belonged in PAM, and it might have slowed down
the adoption of PAM if it was put in.

thanks, roland



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []