Date: Wed, 11 Nov 1998 08:06:05 -0800 (PST) From: John Polstra <jdp@polstra.com> To: Peter Wemm <peter@netplex.com.au> Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, John Polstra <jdp@FreeBSD.ORG> Subject: Re: cvs commit: src/usr.bin/login Makefile login.c Message-ID: <XFMail.981111080605.jdp@polstra.com> In-Reply-To: <199811110745.PAA09429@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11-Nov-98 Peter Wemm wrote:
> John Polstra wrote:
>> Modified files:
>> usr.bin/login Makefile login.c
>> Log:
>> Remove support for LOGIN_CAP_AUTH. It was never enabled, it was
>> not complete, and it hasn't been touched for 18 months. All the
>> ifdefs obfuscate the code. I discussed the LOGIN_CAP_AUTH support
>> with its author and he agreed that it is a dead end. I am bringing
>> PAM into the tree within the next two weeks. It is much more
>> flexible than LOGIN_CAP_AUTH, and will serve as a superior replacement
>> for it.
>
> I think BSDI threatened to give us their code for the implementation of
> this in order to try and help create a pseudo-standard for their interface,
> didn't they? I don't recall the specifics, I think they wanted to release
> BSD/OS 3.0 or 4.0 first though.
It don't really think it makes any difference. BSDI's interfaces
are inferior to PAM's in several ways. One example: In the BSDI
scheme, each authentication module (an executable) performs its own
interactions directly with the user, e.g., prompting for passwords and
so forth. That's the wrong place for the user interface portion of
the package. It belongs in the application, not in the authentication
module. In PAM, the module (normally a shared library, though
there's a way to support static executables too) performs no direct
interaction with the user. It does all interaction through an
application-defined "conversation function". Thus the application,
and not the module, chooses the appropriate style of communication
with the user. The benefit of this is that one authentication
module can be used unmodified by both command-line and GUI oriented
applications.
Before deciding on PAM, I looked pretty hard at the BSDI scheme too.
(I was paid by a client to find the best solution.) The BSDI scheme
is just really not nearly as good. PAM has more power than the BSDI
scheme and is more flexible. It also is quite a bit less intrusive to
PAM-ize an application than to BSDI-ize it.
I have written PAM modules for passwd, S/Key, KerberosIV, RADIUS,
and TACACS+ authentication, all of which my client is donating back
to FreeBSD. On that job, we have been using PAM with these modules
for several months, and it all really works great. The flexibility
is very handy. And you can add a new authentication module without
recompiling a single application. Just stick it in the right place
and add it to your pam.conf file. I think you'll like it. I know I
do.
John
---
John Polstra jdp@polstra.com
John D. Polstra & Co., Inc. Seattle, Washington USA
"Nobody ever went broke underestimating the taste of the American public."
-- H. L. Mencken
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.981111080605.jdp>