Nalin Dahyabhai wrote:
>
> 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.
This makes sence -- and I know of this. Maybe that was not clear from
my statement. I want it to allow checking only password of current
user.
This is very minor difference between current pam_unix/pam_pwdb and "my"
version, that should be noticiable _only_ if some uid is shared between
two or more usernames:
current way: my way:
pwent = getpwuid(getuid()) pwent = getpwnam(username)
spent = getspnam(pwent->pw_name) return access_denied if !pwent
compare(spent->sp_spwd, password) return access_denied
if pwent->pw_uid != getuid()
spent = getspnam(username)
compare(spent->sp_spwd, password)
Maybe I can not mention this, since functionality is _very_ similar
and will be different only in very special cases.
> > 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.
Ok, this makes sence.
> > 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.
Wow, excellent idea! But: in this case, one need the opposite option
(NOT_try_first_pass). Currently pam_unix returns failure if it was
unable
to authentificate user, and e.g. login will repeat attempt some more
time(s).
But will be AUTHTOKs in place second time? At least when using private
data item (not_set_pass option) it will be here. And we're in trouble.
So, this is not just as simple.
> > 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.
Yeah, this should be true. But again: bigcrypt() is not compatible
with crypt():
strcmp(
crypt("123456789", "aa"),
bigcrypt("123456789", "aa")
) != 0
Yes it is compatible when strlen(passwd) <= 8, but not if > 8.
So, if we use bigcrypt "on our own" in pam_unix, it will not be
compatible with system's implementation (as I remember, that was
your statement that md5 should not be the default since it can
break compatibility -- and I agree completely). And now -- why
to introduce two incompatible algorythms (md5 and bigcrypt) when
md5 is sufficient? Only one argument for bigcrypt that I know of
is a system that have it by default (Digital UNIX?). And this
makes sence.
>
> > 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.
Ok. Thanks for clarification.
> Nalin
Thank you!
Regards,
Michael.
