Re: bunch of questions: pam_unix implementation... (long)

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

 



>1.a.  Iff we have another auth methods (LDAP,NIS+ etc), is this set of
>"magic" passwd values ("x", "*NP*) sufficient?  Maybe this set should be
>extended (e.g. "*LP*" as LDAP passwd, "*NPP*" as nis+ passwd etc), or,
>maybe
>just some magic character (like *) or "strange" password length should
>indicate that condition?  (Condition here: a: password stored elsewhere
>and b: to get it, we need to reset [e]uid).

pam_unix shouldn't have to special cased to deal with different
naming services (except, perhaps, for password changing, but
IMO password changing for different "name" services should be
implemented by independent PAM modules).

>1.b. Why we need to have "special" privileges to get shadow entry stored
>somewhere in network, as with nis case?  There is no such concept of
>"network
>user id", at least local unix uid can't be correated to "network uid".

Some NIS servers will only return the password if you're coming
from a priveleged port. With our LDAP/NIS gateway, the shadow
and adjunct maps don't exist as far as clients coming from non-
priveleged ports are concerned. This is not particularly secure,
but it may be better than nothing.

>4.b. Is there any way to clear shadow file buffer, and should we clean
>it and other shadow (crypted) passwords so carefully?  I see e.g.
>`pam_overwrite(salt); salt=NULL' code fragments -- are them necessary
>without cleaning up buffers that are used by getspnam() etc?

Maybe use getspnam_r() instead of getspnam()?


-- Luke
--
Luke Howard | Darwin Developer | PADL Software Pty Ltd
www.padl.com | lukeh@darwin.apple.com | lukeh@padl.com





[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux