Luke Howard wrote:
>
> >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
But pam_unix should know where to reset [E]UID; and should know when it
should attempt to get shadow entry and where passwd entry from
getpwnam()
is sufficient. I agree that it should know little about where shadow
really comes from; but should it be used (shadow) at all and if we need
at least some uid manipulation to get it. That magic pw_passwd values
used in current pam_unix for exactly that purpose: if pw_passwd = "x",
use getspnam(); if it is = "*NP*", reset uid and again call getspnam();
in all other cases, just use pw_passwd directly (no shadow at all).
> (except, perhaps, for password changing, but
> IMO password changing for different "name" services should be
> implemented by independent PAM modules).
Also agree completely that pam_unix should not implement password
changing; but it's current incarnation do implement this, so we will
break compatibility if that ability will be removed. Maybe it should
implement at least changing of /etc/shadow (amongst "pam_passwd_files"
module that I want to write also).
This issue already was discussed here... Compatibility and simplicity
are concerned: pam_unix _should_ be able to modify passwords at least
in /etc/shadow, and maybe in nis (BTW, is nis that useful for storing
passwords so that even this compatibility should be concerned? It is
very insecure for this purpose, at least with current linux
implementation --
passwords (well, shadow entries in crypted form) are walked in
network...)
> >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.
I see a note about privileged port. But this is another issue in
additional :)
So, for some NIS servers we should _NOT_ reset our uid as pam_unix
currently does! BTW, maybe this should be a nis client implementation
issue -- to deal with uids -- not the pam_unix (pam_nis) one?
Can we simple remove that setreuid() fragments from pam_unix??
And let the library to set/reset uids if available/needed?
If so, the only thing that pam_unix should know about value of pw_passwd
field is if shadow entry present (or should be) or not (i.e. if it's
value
is "x" or not)...
Can Steve comment on this please?
> >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()?
Two issues with this: getspnam_r() is not portable (in glibc manual
it is marked as "GNU Extension"). And if getspnam() implemented via
nss_files (or the like), it will use some file pointer internally
(probably FILE*), that have it's own buffer, that holds far more
passwords
for other users... The buffer issue is more serious than "entry" issue
--
we probably can just clear area returned by getspnam() (memset(sp, 0,
sizeof(*sp)),
so getspnam_r is not very useful (probably) here (btw it _maybe_ useful
in pam modules, and other getpwnam_r etc to ensure that pam will not
clash
with application itself).
> -- Luke
Regards,
Michael.
