[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Checking already-in-hand passwords (was Re: MD5 compatibility...

"Michael K. Johnson" <johnsonm@redhat.com> wrote:
> Charlie Brady writes:
> >On 13 Jun 1997 warwick@mmm.co.uk wrote:
> >>
> >> Checkpassword is something with similar aims to PAM, but which works by
> >> splitting a suidroot process into the suid bit and the function-as-user
> >
> >Or add PAM then never have to re-write the glue program again :-)

Heh. I did add PAM: I PAMmified checkpassword, without having to hack about
with qmail-pop3d's code, which is the idea of checkpassword. :)

I don't like checkpassword - PAM seems a lot better to me - but I really
didn't see the point in making source-level changes when this particular
hook had been so generously provided; besides which, if someone uses
checkpassword, they can also now use PAM.

> >> I mention this merely because it's an alternative to assuming that the
> >> first non-hidden user-input request from PAM is the username, and that
> >> the first hidden user-input request is the password - pam_checkpassword
> >> sets PAM_USER and PAM_AUTHTOK directly.
> >
> >Well yes, but this doesn't help in porting existing monolithic programs,
> >which is where I and others started out.
> Actually, it no longer helps at all.  Setting PAM_AUTHTOK directly
> violates the PAM standard, and in the latest versions of Linux-PAM
> the framework explicitly zeros PAM_AUTHTOK before calling the
> modules.

The pam_checkpasswd.so *module* sets PAM_AUTHTOK, based on the data in fd3,
not the program having the conversation - does that still violate things? 
What you say above seems to imply that only the program having the
conversation shouldn't set it, which it isn't (except indirectly by loading
fd3).  Of course if pamd arrives at some time to handle the PAM side of the
conversation, then fd3 will no longer be valid.

Assuming modules are still permitted to change PAM_AUTHTOK, it would be
possible to squirt the username and password in, unambiguously, by writing
them to fd3, and requiring pam_checkpassword.so to be first in pam.conf to
pick it up.

It's not as clean as a formal mechanism (and I only wrote this to handle
qmail-pop3d's checkpassword anyway, so I'm not particularly advocating it),
but assuming anything at all about the order and nature of generic hidden
and unhidden text requests from umpteen arbitrary PAM modules seems a lot
dirtier than this mechanism to me.

> The only reason for it not to go in is that it would encourage people
> to pamify apps in a "dirty" way even when the option exists to do it
> the right way, because there are no protocol constraints.  Understand

It would encourage them to do it the clean way if the clean was as easy
to write as the dirty way. :)

.-----------------------------------. mailto:warwick@mmm.co.uk
! Tim Baverstock, Internet SysAdmin !   http://www.mmm.co.uk [/~warwick]
`-----------------------------------'   plan:"Level 1 RFC1149 compliance."

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []