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

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

Charlie Brady writes:
>On 13 Jun 1997 warwick@mmm.co.uk wrote:
>> 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

>My question still stands:
>> > Is
>> > there a good reason that something which does this task couldn't go
>> > straight into libpam_misc?

I'm not aware of any reason that it shouldn't go in libpam_misc.
It's a very necessary function for limited protocols.

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
that I speak as a guilty party; out of X ignorance, I was unable to
write a proper X conversation function, so my pamification of xdm is
dirty in this way.  Fortunately, libpam_misc is gaining an X conversation
function that should solve this problem in the long run.

I think that the correct way to encourage folks to pamify applications
correctly is to offer as many truly useful helper functions in libpam_misc
as possible.  To that end, a "dirty" check_this_user_authtok() function
would be a start.


"Magazines all too frequently lead to books and should be regarded by the
 prudent as the heavy petting of literature."            -- Fran Lebowitz

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