Re: xlock (was Re: libcrypt info)

[morgan physics ucla edu (Andrew Morgan)]

Marek Michalkiewicz wrote:
> 
> Al Longyear:
> > That type of logic is what would probably be helpful to programs such as   
> > the xlock code since you can not really do the conversation with a   
> > formatted input field. :)

Formatted fields are a little harder to interface with PAM. But it
should be possible to work them in. Basically there are four forms of
input/output "atoms" of communication that a conversation function
should support.

	* prompted input (echoed)
	* prompted input (non-echoed)
	* informative text
	* error text

In an X(or other windowing environment) this could be handled in a
number of ways. Some of these are likely to mimic well the current
(non-PAM) behavior of the application. And others not. As an interim
measure it might be simplest to implement all four of the above
interaction types with a dedicated dialog box, that appears when the
conversation function is invoked, and disapears when the user hits
return, or clicks <OK> etc.

In the longer term the conversation function could dynamically
generate a form, based on all of the individual interactions that can
be simultaneously done in a single call to the applications
conversation function.

> One problem with xlock: it currently gets the encrypted user's password
> at startup.  This is good, because:
> - it can terminate early with an error message if it can't get that
>   information
> - it can drop privileges as soon as possible
> But PAM doesn't (correct me if I am wrong) have the concept of "get

You are completely right. It is hard to see how this would be
pluggable though. Since getting the encrypted password and knowing
what to do with it, is very authentication scheme dependent.

> all necessary information now, to be able to authenticate the user
> later".  Now, suppose it's a NIS environment, pam_authenticate is
> called because the user wants to unlock the display.  Now, how should
> errors (say, the NIS server went down) be handled?
> - fail the authentication (normal for login, ftpd etc.): no way to
>   unlock the display and save your work
> - unlock the display (so that you can save your work): let's unplug
>   that box from the network for a while to get in...

This is likely to be a problem. Apart from the fact that the user is
likely to have trouble saving things to remotely mounted home
directories anyway, network failures should be treated with great
caution---least they be exploited by some clever hacker. It is
possible that a well constructed pam.conf file might have a
"sufficient" NIS entry followed by a "required" "RootMayLogInForYou"
entry... In this way it would be possible to get control
back. (Although, in the heat of a network failure, finding a sys-admin
with time to let a user defeat xlock might be wishful thinking ;)

> FYI, xlock is not listed under "programs known to use PAM" in my copy
> of the Sun's PAM postscript documentation.

True. But it only seems right to try and cover all authentication
granting applications... If we have the people..?

> > It is true that the MD5 logic is not really part of the PAM password   
> > suite. However, the calls to both update the user's credentials and the   
> > call to validate the credentials, are. This means that, while crypt does   
> > not need to be replaced in the library, there is no reason that crypt   
> > must be used. The pam module is perfectly valid if it does not use crypt   
> > but its own method of validating the credentials.
> 
> In general yes, but pam_unix is special (compatibility with existing
> password files and applications which are not yet PAM-aware) so I think
> it should use crypt() (at least for now).

IMHO, the keep it simple rule should apply to modules. This is after
all one of the advantages of a modular approach to authentication.  I
think MD5 password encryption should be its own module. A pluggable
replacement to the unix one. I'd opt for pam_unix vs. pam_unix_md5
modules that take an optional "shadow" argument to indicate where to
actually find the encrypted password. In the long term it is likely
that the need for crypt() will vanish [unless the current controversy
as to whether one can constuct messages for 'any' given MD5 digest
turns out to be real.. (see news:sci.crypt for more info) RIPEMD-160
would be another alternative.]. What ever happens, it is vital to
provide modules for all of the currently popular authentication
schemes...

Regards

Andrew