For the first, thank you Thorsten for your comments -- I was hope
that you read all of this my crap... :) I say so here because I
hear that you has some enhancements/patches/etc for current pam_unix
module,
and I'm very interested in getting that ideas and your opinions...
Thorsten Kukuk wrote:
>
> On Sun, Aug 13, Michael Ju. Tokarev wrote:
>
> > In current pam_unix code, it is done by comparing pw_passwd field with
> > "x" (to mean "plain shadow file") and with "*NP*" (to mean "Nis
> > Password"),
>
> Wrong. *NP* means you are not allowed to see the encrypted
> password. You will get this, if you are not allowed to see
> the password on a NIS+ server.
Oh, more knowledge each time -- I now understand more... :)
And I better see now comments around that places in pam_unix...
I'm lazy sometimes, sorry me...
And I now understand the logic with setreuid() (Actually I used NIS+
on Solaris some time ago -- and was curious about why user is allowed to
see his own password, while root does not...).
So -- if getpwnam() returns "*NP*" in pw_passwd field, than we should
set uid to that of pw_uid and try getspnam(); and if pw_paasswd has
another value, we should just call getspnam() with our current uid,
right?
And this will work for any network system that works that way (i.e.
*NP* is an indicator that you should have correct uid if you want to see
that password, and you chould call getspnam() -- right?)
But see next entry....
[]
>
> > 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).
>
> This "x" and "*NP*" has nothing to do with PAM, it is implemented in the
> database. So you need to change NIS+ and LDAP, but not pam_unix.
But the question remain -- 3rd time... -- how pam should get real
(encrypted) password stored in system/network/etc and _all_related_info_
available in shadow entry? How it should decide if it should call
getspnam()
or use pw_passwd directly as crypted password, and if it should set uids
before calling getspnam()... How NIS+/LDAP should be changed so that
pam will not deal with "x" and "*NP*"!?
After your explanation, "x" and "*NP*" and all setreuid() magic looks
almost good for me... But you tell that pam has nothing to do with
them...
I'm confused entirely...
> > So, the enforcement from nis client library (to get shadow entry of some
> > person you should have uid equal to uid of that person) is not
> > practically
> > useful, since it is just easy to modify nis client code (compile it by
> > itself, implement it in perl etc) to avoid such enforcement.
>
> Recompiling does not help you, because than secureRPC will not longer
> work and you cannot authenticate yourself against the NIS+ server.
> This means you will never get the password.
I mean nis here, not nis+. And now I see that I was wrong -- actually
that issue was with nis+. So at least some of my questions are answered
already -- nis+ has other principles, where this (and the like)
questions
have no meaning.
> Thorsten
Thank you!
Regards,
Michael.
