On Sun, 13 Aug 2000, Michael Ju. Tokarev 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 was built the way it was so that NIS and NIS+ could be handled
transparently by the same module, without having to reconfigure anything.
This was deemed the most convenient solution for administrators, and the one
most like traditional Unix authentication. Because /etc/passwd, /etc/shadow,
NIS, and NIS+ are all "traditional" Unix authentication methods that predate
NSS, putting them all in the same module gives us better compatibility with
existing systems. There is also no reason that switching between these
options should require reconfiguration of PAM, because it's possible to
autodetect, as pam_unix currently does.
LDAP is a different case. An administrator wishing to use LDAP for
authentication must make configuration changes to NSS. Moreover, pam_ldap
doesn't use the getpwnam(), getspnam() system calls for authentication.
Adding LDAP support into pam_unix() would make it much more complex than it
needs to be, especially since there's no way to automatically determine a
*preference* for either NSS (getpwnam) or LDAP-based authentication.
So LDAP gets its own module, and everything that can be done through NSS goes
into pam_unix. Then the administrator can stack the modules however he
chooses.
> 1.c. It will be nice if we can determine _why_ shadow entry unavailable.
> If getspnam() returns NULL, what a cause? Maybe it just does not
> exists, maybe there are unsufficient privileges to get it (we are not root,
> or nis [e]uid issues etc). Does anybody knows how to do this? I looked to
> glibc source, it seemed to me that "files" implementation of getspXXX()
> sets errno=EACCESS in case we are not root (as from fopen()), and we
> already can catch this, without using errno (if we are shure that shadow is
> in /etc/shadow), but network implementations are not so nice in this
> respect.
How important is it to know why the shadow entry is unavailable? If it's
useful for debugging, maybe it's better to log something when the debug flag
is turned on, but leave the return code alone. I'm not sure how much we want
to expose to the user here.
> 3. setuid binary helper. I see a little demand on this (I was very
> curious why it was implemented, untill I found at least one application
> that can rely on it -- it is xlock and the like). Should we really
> implement this helper? Maybe xlock should have it's own helper instead?
> And if should:
> it seemed to me that this helper should accept a username entered, and
> not
> rely on getuid() -- if we have some "users" shared one uid, e.g. for
> mail access, this helper should _not_ check "mail owner"'s password,
> but mail user's one... In other words, it should accept username,
> and verify if this username have uid equal of those user running the
> helper, and _not_ as it does currently (checks password of user
> determined
> by uid).
I find your example puzzling. Why would this mail software have more than one
username mapped to the same uid? Although it's possible to hack the user
database to make this work, I think it's a bad idea to support this explicitly.
Many programs expect a one-to-one mapping between usernames and uids.
> is should be unnecessary to call helper from pam_unix when there is
> no password record available (getpwnam() returned NULL) or if uid
> returned by getpwnam() does not match our uid returned by getuid(),
> isn't it?
> DoS attacks for example...
I agree. There's no reason to call the helper binary if getpwnam() returns
NULL, and there are several reasons not to.
> 3.a Maybe this helper should be used to change password also?
> But in this case I don't know how to avoid it's usage directly, thus
> allowing users to have passwords of bad quality -- without e.g.
> pam_cracklib...
I don't think a helper binary is necessary for password changing. Users
should be using 'approved' programs (suid root) for changing their passwords,
so there shouldn't be a need for a helper, should there? If we need a
standard helper of any kind, it should be a helper program that *calls* PAM
functions, not one that is called by pam_unix.
> 4.a. why current pam_unix uses "strange" method of "storing" password
> afetr a user prompt? Here is a simplified code:
> pam_converse(..., &resp, ...);
> pass = strdup(resp[0].resp);
> pam_drop_reply(resp);
> Why strdup(), and have another possibility to return PAM_BUF_ERROR?
> Why not just use:
> pam_converse(..., &resp, ...);
> pass = resp[0].resp; resp[0].resp = NULL;
> pam_drop_reply(resp);
I don't see any reason why this can't be done the way you describe.
Steve Langasek
postmodern programmer
