Subject: Re: Philosophy of PAM and rc.d
To: Miles Nordin <carton@Ivy.NET>
From: John Nemeth <jnemeth@cue.bc.ca>
List: current-users
Date: 03/19/1999 03:24:10
On Mar 17, 9:31pm, Miles Nordin wrote:
} On Tue, 16 Mar 1999, Thor Lancelot Simon wrote:
}
} > Is there a good argument against PAM
}
} 1. lack of support for S/Key, KerberosIV, and GSSAPI.
So, write a module to do those. At least you only have to write
the module once, rather than implementing it for every application you
have that does authentication.
} 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.
These are not mutually exclusive concepts. When it comes right
down to it, most users use a plain passwd file (possibly with some
form of shadowing).
} 2. flakiness (still) of the current versions of PAM, and likelihood of
This is an attribute of a particular implementation, not of the
API, and therefore doesn't belong in a discussion of whether NetBSD
should adopt PAM.
} substantial future architectural changes in PAM. unlikelihood that
So what? Everything is open to change.
} the NetBSD project would have much influence on these changes, which
} would intimately affect the source tree.
No, it wouldn't. NetBSD could do anything it wanted with its
implementation as long as it followed the "standard" API, so that
third-party apps would continue to work.
} 3. likelihood that future versions of PAM will become needlessly
} complex, as its advocates try to compete feature-for-feature
} with Solaris.
There are at least three (four?) major versions of UNIX using PAM
now. I don't think this is that much of a problem.
} 4. good, consistent, shadow-capable authentication support already in the
} NetBSD tree (something Linux didn't have, which largely motivated the
} adoption of PAM)
There is a lot more to PAM then just shadow password files.
} > 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
This isn't unusual. I've seen this problem with a number of SysV
variants. That's why when people were talking about adding
/etc/rc.shutdown, I was pushing for a timeout.
} it works better with vendor package management software. many UNIX
} sysadmins are not comfortable editing text files, and prefer to use HP's
} sam or RedHat's glint. however i think people ditch vendorware in favor
These people are not sysadmins, they only play at being one.
}-- End of excerpt from Miles Nordin