From owner-cvs-all Wed Nov 11 08:06:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA01059 for cvs-all-outgoing; Wed, 11 Nov 1998 08:06:27 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA01054; Wed, 11 Nov 1998 08:06:23 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id IAA15797; Wed, 11 Nov 1998 08:06:05 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.1/8.9.1) id IAA09954; Wed, 11 Nov 1998 08:06:05 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199811110745.PAA09429@spinner.netplex.com.au> Date: Wed, 11 Nov 1998 08:06:05 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Peter Wemm Subject: Re: cvs commit: src/usr.bin/login Makefile login.c Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, John Polstra Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk 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