RE: libcrypt info

[Al Longyear <longyear sii com>]

Marc,

It **WAS** a sort of 'major rewrite' to the yacc parser for wu-ftpd to   
support the PAM library. The actual problem was not in the yacc parser,   
but in the functions (in the "C" main code) which are called by the yacc   
parser to process the "user" and "pass" commands.

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.

[To be really honest, of all of the code which I have contributed, the   
pam_passwd+ code is the one which has been "hacked" the most. It only   
vaguely resembles the original text.]

I have only completed the wu-ftpd process. It is the one which __I__ use.   
I promised to do the BSD one and will. I just haven't completed (nor   
started) on that version yet.

I do have a small module for doing things such as the pppd process,   
poppasswd, popper POP daemon, IMAP daemon, etc. It is a simple module   
which just sends fixed strings to the conversational hook to request   
items such as the user name, password, and optionally, the new password   
fields. No authentication is performed by this code. It is meant to be   
stacked upon some other authentication code. However, it does get LEGALLY   
around the problem of not being able to set the passwords from the   
application and at the same time does permit the application to recognize   
the requests for the data.

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

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 fact, it may be a good idea if the module does *NOT* call crypt() --   
at least for a short time during the initial testing. It would mean that   
the applications which should use PAM but don't will fail to do the   
validation sequence. This will help find the problems and 'missed'   
applications.


 ----------
From:  Marc Ewing[SMTP:marc@redhat.com]
Sent:  Monday, June 10, 1996 6:04 PM
To:  pam-list
Subject:  libcrypt info


 ------- Forwarded Message

From: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>
Message-Id: <199606102144.XAA08386@i17linuxb.ists.pwr.wroc.pl>
Subject: Re: ANNOUNCE: Shadow + Red Hat (and more) RPMS and source now
To: marc@redhat.com (Marc Ewing)
Date: Mon, 10 Jun 1996 23:44:49 +0200 (MET DST)
Cc: shadow-list@neptune.cin.net, shadow-list@redhat.com

> > Why impose the use of libcrypt now and later on drop it on the floor   
and
> > switch to libPAM ? It is going to be messy, IMHO. Keep it simple,   
stupid,
> > someone said once... :-)

I think libcrypt can still be used by the pam_unix module.  All it
does is to provide a modified crypt() which supports both the old-style
(DES based) and the new MD5-based algorithm.  It has been done before -
see FreeBSD libcrypt (in the "secure" part of the distribution,
distributed from outside the US).  It may well be integrated in libc,
but I think it is better to keep it separate so it can be replaced
more easily.

libpam will not replace libcrypt.  All it takes to use libcrypt is to
link the program with it.  It will be even easier as soon as ld.so
1.8.x goes out of beta testing - just edit /etc/ld.so.preload and no
programs need to be rebuilt at all.  I don't think it is messy.

One thing I can't do with libcrypt is to port it to the Alpha and make
sure it gives the same results (I heard that even the regular crypt()
had this problem for a while).  Anyone?

> The next release of Red Hat will be PAM based, and it will include
> shadow support.  The PAM stuff is still quite new, and only a few
> programs have been retrofitted for PAM support.  The PAM effort

I don't know when the next release is expected, but I think the
hardest part of PAM will be modifying applications (as I understand,
the PAM library itself is almost working).  For ftpd it looks like
a major rewrite (the current design using yacc parser doesn't really
lend itself very well for PAM conversion).  Someone will do it sooner
or later (when more UN*X vendors start using PAM) but it may take
another major kernel version...

It's not my decision, of course, but it would be nice if the new
Red Hat release was not delayed until PAM is ready.  I admit that
shadow isn't perfect, but it works and is expected to be ready much
sooner (especially now that it should receive more testing from
people using the just released shadow RPMs).

It is possible to have some applications (like login) use PAM and
others (like ftpd) still the traditional shadow API.  So the next
Red Hat release could well be half-PAM-based :-).