[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pam-list
Subject:    libcrypt info
From:       Marek Michalkiewicz marekm () i17linuxb ! ists ! pwr ! wroc ! pl
Date:       1996-06-11 1:11:04
[Download RAW message or body]

Al Longyear:
> However, that is complete and part of the current PAM distribution. It   
> does work with the only authentication methods available today -- UNIX. I   
> "HOPE" that it will work with the others. I have not tested it.

Good to hear that.  At the very least it should be tested with the
skey module (when it is ready) too.

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

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

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

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

Marek

[prev in list] [next in list] [prev in thread] [next in thread]