Re: PAM, Potato, Packages -- things that begine with 'P'

[Steve Dunham <dunham@cse.msu.edu>]

Ben Collins <bcollins@debian.org> writes:

> On Tue, Mar 02, 1999 at 06:20:53PM -0500, Michael Stone wrote:
> > > No, wrong, false. If you are just using local files in /etc, then you are
> > > ok, but the biggest reason for using PAM is having the ability to use
> > > special authentication sources. Like radius, LDAP, and whatever else you
> > > can think of. This means that there is no local authentication method for
> > > non-pam apps.

It's also useful if you want to add logging, time of day access
control, remove securetty, etc.

As far as the lesser clued are concerned, Red Hat seems to get away
with using PAM without much trouble from users.  Red Hat has been
using PAM for a very long time.  (PAM is on my list of things that RH
does better than Debian.)

> > > The way it helps users is by not forcing them to use PAM, some people
> > > don't want it. This may be overidden if we see that PAM is stable enough
> > > to support as the standard (currently, being familiar with the source, I
> > > don't have that confidence), but initially we need alternatives.

> > If you really want them, go for it. But I'd advocate telnet-nopam, etc.
> > Either we're going with pam or we're not. I don't have anything against
> > providing optional non-pam packages, but they shouldn't be the defaults.

> If that is how everyone feels, then it is fine with me, I'm only giving
> my suggestions. I'll support the libraries as best I can no matter what
> the general decision is.

IMHO, we should just PAM-ify everything and setup the default config
files to emulate the old behaviour.  RedHat has been using PAM for
quite a while and the


BTW, the best way to go about PAMifying everything is to grab the
equivalent RedHat source package and extract it.  All of their PAM
patches are in seperate diff files, so they should be easy to borrow.
(Multiple diff files are really handy - witness the hacks in the egcs,
gdb, and other assorted Debian source packages to apply diffs at build
time rather than when the source package is extracted.)


Steve
dunham@cse.msu.edu