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

Re: GDBM/DB password file support

On Thu, 10 Oct 1996, Elliot Lee wrote:

> The problem there is making a pam_nis module. libc & NYS make using NIS
> easy, but I think that is pretty complicated to integrate just that stuff
> into a separate program. Using ypbind is not desirable on many systems.
> Ideally we *should* have a pam_nis module, but how far do we take it? Do
> we tell pam_unix_auth to use fgetpwnam() to only read /etc/passwd, and
> then have pam_nis_auth read only the NIS database? Why do that when
> getpwnam() gets information from NIS very nicely, and also allows usage of
> libc's superior (?) integration between /etc files, NIS/NIS+, and
> sometimes DNS.

Agree with you said above. NIS is just ugly. The fact that it "magicly"
makes functions like getpwname() return NIS information by using a magic
token (the "+") in the password file is a hack. As such we now have
/etc/nsswitch.conf. This all should have been done with PAM and GSS, but
they came in to late. In my perfect world there is a library with NIS
specific code, a library with shadow specific code, and a library for code
that overlaps. You have a module for unix, a module for, NIS, a module for
shadow, and a module for Radius. They might share code but they are
distinct modules. And the only configuration file is /etc/pam.conf.
But I'am a dreamer.

> It would be nice to have a pam_nis_passwd module, though, since password
> changing only works for local users right now (even though NIS users can
> still login).
> Basically, since libc is doing NIS functionality already for things other
> than authentication, why not let it get the auth info for PAM as well?
> Perhaps what needs to be done is find a way to use the low-level NYS stuff
> from libc in an application or PAM module.

All authentication code (expect maybe regular /etc/passwd) should be
ripped out of libc. After all this is the pluggable *authentication*
module interface. If something needs to do authentication it should use
PAM and/or GSS.

> Or we could look at the glibc functionality and use that idea...?

Read above.

> My opinion,
> -- Elliot
> "Have you ever had a microchip implanted in your skull so the government
> can keep track of your every move? You will! And the company that will
> bring it to you is AT&T"
> --
> To unsubscribe: mail -s unsubscribe pam-list-request@redhat.com < /dev/null

Aleph One / aleph1@dfw.net
KeyID 1024/948FD6B5 
Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01 

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