On Sat, Aug 19, 2000 at 03:26:25PM +0400, Michael Ju. Tokarev wrote:
> o suid binary helper should accept username as argument -- I still
> think that it should use getpwnam() instead of getpwuid(). Thus,
> it will not be compatible with current pam_unix implementation.
The current setuid-helper checks the UID specifically to make guessing
passwords harder. This keeps you from being able to use unix_chkpwd
to guess other people's passwords unless you're root. It breaks servers
that run as non-root users, but I think it's still worth doing.
> o new proposed options to session stack: utmp, wtmp and lastlog,
> as I think that them belongs to pam_unix as module name says
> (things specific to unix ;). Session stack in pam_unix currently
> just empty (except of two syslog calls). And some details about
> this ones (them are just planned -- when I finish/polish other stuff).
I'd prefer utmp/wtmp stuff be handled in a different module. You're
mixing Unix authentication with other traditionally-Unix bits of login,
when it makes perfect sense for someone using other auth methods to
want to have that same capability.
> o option for passwd stack to _not_ to ask _new_ password and get it
> from pam item. {use,try}_first_pass is not sutable here (them
> both used in the same stack also), use_authtok is not so consistent
> in other modules as the first two. I use `use_new_pass' here
> for this purpose, and this may be wrong thing to do
What seems to work best in this case is to have whichever module
is prompting for the two (or three) passwords to always save them
to the PAM_AUTHTOK and PAM_OLDAUTHTOK items, and for modules to
only prompt for values for these if they're not already set.
> bigcrypt
> ok, it is not so good as md5, why it ever needed when "plain"
> crypt()
> and md5 exists?
A properly-written bigcrypt() gives you different outputs for
"passwordwithextraletters" and "passwordwithmoreletters", because
regular crypt() only considers the first eight significant.
> o I don't know why `likeauth' (undocumented) option needed.
> Why just not have corresponding entry point in module?
> I currently implemented it, but not shure why :)
Consider the case where you have pam_unix "sufficient" and another
module "required" being used for authentication. The pam_unix auth()
function fails, but the other module succeeds. If pam_unix was not
passed "likeauth", the setcred() in pam_unix is called and returns a
successful code, and the setcred() in the second module is never
called. This is unfortunate when the second module's setcred() needs
to be called for things to work correctly.
Nalin
