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

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

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
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,
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
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
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)
have no meaning.

>   Thorsten
Thank you!


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