On Wed, 17 Mar 1999, Miles Nordin wrote:

// > Is there a good argument against PAM
// 
// 1. lack of support for S/Key, KerberosIV, and GSSAPI.
// 
//   i realize there are likely to be some development versions of PAM
//   libraries that do these things, but in my experience such projects are
//   often abandoned before they become nearly as reliable as their
//   (currently working) alternatives.  we should consider them existant
//   when it seems inevitable that they will become reliable.
// 
//   i suspect most PAM users do not use Kerberos or S/Key, and that most
//   Kerberos and S/Key users do not use PAM, and base my judgement partly
//   on this.

	I use kerberos 5, so I don't much care about Kerberos IV support.
Both kerb versions seem to be supported, as well as s/key.  It's pretty
easy to assume that most PAM users don't use kerb or s/key, I could easily
say that I don't believe most UNIX users in general use kerb or s/key.

// 2. flakiness (still) of the current versions of PAM, and likelihood of 
//    substantial future architectural changes in PAM.  unlikelihood that 
//    the NetBSD project would have much influence on these changes, which 
//    would intimately affect the source tree.

	I'm not sure about the flakiness parts, but even if the
architecture does change, there is a *huge* gain simply by having the
authentication pluggable.  I.e. I would like to make some my systems use
RADIUS (or LDAP) for authentication.  The only thing that's stopped me in
the past is the amount of pain it would take to get all of the little
details working.

// 3. likelihood that future versions of PAM will become needlessly 
//    complex, as its advocates try to compete feature-for-feature
//    with Solaris.

	Again, not everything has to be implemented.  I can imagine more
work will be done in the modules than in the API itself.

// 4. good, consistent, shadow-capable authentication support already in the
//    NetBSD tree (something Linux didn't have, which largely motivated the
//    adoption of PAM)

	I disagree completely here.  Shadow doesn't answer my need for
kerberos, s/key, RADIUS, LDAP, etc...

// > or modular rc scripts?
// 
// i have several NFS-rooted NetBSD boxes, and one NFS-rooted Linux
// box.  All the NetBSD boxes can halt or reboot just fine, but the
// RedHat box cannot.  I have fixed two rc.d-related problems that get
// it _closer_ to rebooting, but it still won't go all the way.

	I don't understand what this has to do with modular rc scripts.  I
didn't say bad rc scripts, just modular.

// i feel this system would better justify its unfortunate complexity
// than the rc.d improvement.

	I'm not asking for complexity, I'm asking for simplicity.  Small
units that only do what's required to get one thing working each.

// i think contributors (and presently mere `enthusiasts' like myself)
// would do well to advocate a deeper, sometimes mysterious and
// questionable philosophy--rather than being ashamed of our collective
// laziness merely because someone makes a chart of Free-UNIX features,
// and NetBSD lacks a check mark.
// 
// this, my brothers, is something to be proud of.  let us earn no more
// check marks than we must!

	I agree, but when one of those checkmarks keeps me from having to
wire in proprietary authentication pieces to every single piece of
software I install, I think the ink can be justified.

--
Principal Member Technical Staff, beyond.com    The world is watching America,
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE 
L______________________________________________ and America is watching TV. __