On Sun, Aug 13, 2000 at 05:57:35PM +0400, 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).
I think this was more important when you had individual applications
handling all of their authentication tasks, and this was the only
mechanism you had for specifying a particular authentication scheme.
For example, the magic string for using Kerberos for authentication
is "*K*", but it doesn't get used very often.
The use of "x" for indicating that shadow information is available is
a useful thing -- without it, the application (or a module, in PAM)
would need to try looking the information up for the user, and an error
looking up the shadow information is only an error if you know it's
supposed to be there.
> 4.c. Can anyone comment -- does we really need to support "brokencrypt"
> (that was a bug with endianess issues) that was discussed in this
> list already?
This is in there for dealing with md5 passwords that were hashed
incorrectly -- I don't really know when it'll be "safe" to take
that code out. It would have to be done with lots of advance
warning, at least.
> 4.g. Should we ever support "plain" crypt? pam_unix have "md5" and
> "bigcrypt" options, and by default should use "plain" crypt. Should
> this
> behawour be preserved, or that options should be just ignored and "md5"
> used always? This may break some compatibility, so answer probably
> "not"
> here. But I can argue against "bigcrypt" option -- it should be noop.
No, we need plain DES crypt for the same reasons you describe.
Compatibility with every other platform out there (except for the ones
that have a port of Linux-PAM running on them, or md5crypt build into
their libc) would be gone. I think we'd even be incompatible with
Solaris.
> 4.h. currently pam_unix always sets PAM_AUTHTOK (or private item) after
> asking password _before_ it checking. It should set this item only
> after
> _successeful_ checking, and clear it on each unsuccesseful attempt,
> isn't it?
> And it should clear it if it permits empty pass (see 2. also), isn't it?
Nope. Consider a stack where you want the user prompted only once
for a password. Modules after pam_unix can be supplied with the
"use_first_pass" argument to just use the value the pam_unix module
got from the user, and not prompt for another. Both pam_ldap and our
pam_krb5 allow this, and it's very useful for environments where
multiple authentication schemes are in use.
Nalin
