[ On Thursday, September 26, 2002 at 12:35:07 (-0400), Ross Patterson wrote: ]
> Subject: Re: Re:PAM
>
> *AND* with full control over the specification and interactions of those 
> methods by the system administrator.

and nsswitch and BSD-Auth don't?!?!?!  indeed they do!  :-)

The "and" is unnecessary and irrelevant -- it is common among all the
techniques we've discussed as alternatives to directly hacking each
application.

> Which explains why PAM has been such a big win in Linux?

Damned if I know why -- though I do recall the furoror over PAM which
got it implemented in Linux before even Sun had their implementation
released happened amongst people who really didn't understand the
requirements fully and who were still relatively very new to this "open
source" stuff, and indeed at that time proprietary unix systems were
certainly still in the vast majority on all fronts.

> You're confusing "user" with "programmer", and in many cases with 
> "sophisticated programmer".

No, I am most certainly not.  Any unsophisticated user is able to hire a
sufficiently sofphisticated programmer to do such integration on their
behalf if necessary, however in an open source system it's quite likely
that such integration will be done and made freely available to the
community for any sufficiently interesting and widely used A&A scheme.

"User" in this case refers only to everyone not actively working
directly on the "official" system sources.

Even third party developers such as myself are "users" of the code base.

Unsophisticated end users don't have to get their NetBSD binaries from
ftp.netbsd.org.  Indeed vendors of proprietary authentication schemes
could quite easily provide NetBSD binaries containing their code,
especially if the framework and APIs for integrating such modules are
ready and waiting in the NetBSD code base shipped from netbsd.org,
though it's probably a lot easier for them to just ship .o files ready
to link and install at customer sites (in which case the same .o files
would work for any OS offering the same APIs).  I remember testing
object libraries and binaries for the CryptoCARD(tm) (or at least
something like it -- I forget exactly which) on an AT&T 3B1 back in the
early 1990s.  I'm sure they would have been much happier to support that
machine if they had only needed to provide generic m68k object libraries
and not also various platform and release specific binaries such as
/bin/login.  PAM would be one means to that end, but it is far from the
only one, and probably far from the best too.

> I've never tried to use it this way, but from what I read it's possible to 
> statically link a PAM environment if the individual modules support doing so 
> (as all of the common examples in the Linux-PAM package do).  Certainly the 
> code-delta to support static linking is very small - a few dozen lines and 
> using some cpp symbols.

I can imagine several ways to fool any individual PAM module into being
static-linked directly into the likes of /usr/bin/login, ftpd, etc.,
even without assuming the PAM framework is supported in those programs.

I can even imagine several ways to fool the PAM framework into static
linking several different individual modules into various programs and
still allowing the configuration files to specify which will be used
when and how.

After all this is really no different except in the details to what we
already mostly have in nsswitch.

What I'm not sure of is where the benefit is over what we already have.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>