On Sun, Aug 13, 2000 at 09:53:11PM +0400, Michael Ju. Tokarev wrote:
> 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...).
And don't forget the new flavor of SecureRPC, where the old
Diffie-Hellman NIS+ system is supported and so is Kerberos and anything
else for which you can supply GSS-API plug-ins.
In fact, if you use Kerberos as the only authentication system then you
won't even have crypted passwords anywhere. Of course, if you're using
Kerberos then pam_krb5 should be tried before pam_unix and should cause
pam_authenticate() to return immidiately on success; this is an
administration issue. But I should point out that on Solaris PAM doesn't
work if pam_unix is not mentioned in an application's PAM configuration.
Also, I thought that NP meant "no passwords", as in "you can't login".
On Solaris, system accounts that are not meant to be logged into have
'NP' in the password field of /etc/passwd.
> 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*"!?
PAM_UNIX should use 'x' and '*NP*' as hints, I guess. It's up to the NSS
modules to implement getpwnam()/getspnam() however they wish (NIS,
NIS+, LDAP, flat files, NetInfo, whatever).
PAM_UNIX should avoid all direct uses of any particular naming service's
APIs. PAM_UNIX should stick to the NSS API (getpwnam()/getspnam()) so it
can work with *any* naming service.
> 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...
I guess the setreuid() magic is due to the fact that different naming
services will require uid/euid to be set as root or as the user, but
since pam_unix won't know which name service is being used (NSS would)
it should just try all the different variations.
[...]
> > Thorsten
> Thank you!
>
> Regards,
> Michael.
>
Nico
--
