Subject: Re: PAM
To: David Maxwell <email@example.com>
From: Jim Wise <firstname.lastname@example.org>
Date: 08/28/2002 12:46:58
-----BEGIN PGP SIGNED MESSAGE-----
On Tue, 27 Aug 2002, David Maxwell wrote:
>On Tue, Aug 27, 2002 at 04:50:52PM -0700, email@example.com wrote:
>> > > - PAM is standard.
>> > "Standard"? I don't think so. It's common, but it's far from being a
>> > real standard. I wonder if the GNU/Linux implementation can even load
>> > and use a binary Solaris plugin (assuming it's for the same target CPU).
>> PAM is a standard. http://www.opengroup.org/tech/rfc/mirror-rfc/rfc86.0.txt
>>From a standards body which I don't believe the NetBSD project has taken
>a complience stance on.
>SECAM and PAL are official standards too. That doesn't mean it would be
>appropriate (or sensible) for me to buy such equipment, rather than
>NTSC, since I'm in North America.
With due respect, the reason (and the only reason, I warrant) that you
would choose NTSC rather than SECAM and PAL hardware is to interact with
what others are doing -- a very good PAL system would still be next to
useless to you, as you wouldn't be receiving anything to use it with.
Well, guess what? The same goes for PAM -- there are a _lot_ of
projects out there working to integrate PAM with assorted databases,
network authentication systems (RADIUS, LDAP, NTLM, netinfo, you name
it) and so forth. If we adopt PAM, we benefit from all of this.
In contrast, there aren't such projects out there for BSD-Auth or for
some alternate `standard' we might invent. This seems to dictate that
we should at least support PAM as a compatibility API.
Now, given that BSD-Auth can easily be implemented as a PAM plugin,
while it is impossible to implement PAM as a BSD-Auth plugin (because
BSD-Auth cannot modify process state), it seems pretty clear where we
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (NetBSD)
-----END PGP SIGNATURE-----