[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 wrote:
> >> > 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

This is exactly the reason why I have not already placed this code in
libpam_misc.  My initial hope was that people would flock to clean up their
spaghetti ("we handle 27 different methods of authentication...")
applications into smaller (verifiable?) PAM based ones.  I wrote a general
conversation function to help out this cause and even rewrote three
applications (SimplePAMApps) to this end.

However, my hopes proved to be premature.  On the one hand people like to
keep using old applications - fixing them up here and there. On the other
hand writing completely new code takes time that most people can't afford.

What has happened instead is that people have liked some of the flexibility
that PAM offers but have shyed away from embracing it all.  POP is a good
example of this.  Reading the POP RFC (1725) it would seem that there are
two defined authentications: USER-PASS and APOP.  The quick hack to PAMify
qpopper only offers support for the former and I'm afraid that this is where
the PAMification process is likely to stop: "it works now so let's move
on...".  In point of fact this RFC points to another (1734 - although I
confess to have not read that one) that discusses other authentication
schemes that could be used with POP.

Also, PAM is not just about authentication.  Most server based applications
have some notion of a session and could easily support the pam_session
hooks...

> 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.

Unfortunately, my fear is that this will simply be an 'end'.

Having said this, I should state that I am pleased that people have at least
made the effort to support PAM in some way... and for this reason, if people
still feel that some sort of dirty_auth code belongs in libpam_misc, I'll
add it :(

Cheers

Andrew
-- 
               Linux-PAM, libpwdb, Orange-Linux and Linux-GSS
                  http://parc.power.net/morgan/index.html



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