[Bug 559] PAM fixes

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=559





------- Additional Comments From fcusack at fcusack.com  2003-05-14 14:28 -------
> > @@ -186,8 +186,8 @@ input_userauth_request(int type, u_int32
...
> This chunk is not necessary, as userauth_finish does: 

I didn't want to
second guess what userauth_finish() would do (for maintainability going
forward).  Prior to the patch, userauth_finish() would never be called
with authenticated=1 && authctxt->valid=0.  Hence the fatal(), I guess!
I wanted to preserve that assumption.

> and no auth method should set authenticated = 1 for a non existant user :)
 
You can't know what PAM will do.  I had another patch where getpwnam()
wouldn't run until after PAM was called.  This gives PAM the chance
to change the username, which it's allowed to do.
 
FWIW, I actually have a valid use for that behavior (not just having a
feature for feature's sake).  A device that
logs folks in to a single role account, but using individual usernames
and secrets.  Via PAM, that's possible to setup so that (eg) the auth
goes to radius for secret verification, then the last module in the
stack changes the username.  The advantage is: no account maintenance
on the device.  I couldn't use the :style nicety because that is already
used to access specific features when logging in.  (I could have done
something like :user.style but opted for PAM--seems cleaner.)
 
But regardless of that use, again, you cannot know what PAM will do.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.