Subject: Re: Shadow problems

From: [email-masked] (Bruce Perens)
Date: Sun, 18 Aug 96 19:14 PDT

Let's plan on having "shadow" be part of the base for 1.2 . We should thus
have the default "login" be aware of it, etc.

	Thanks

	Bruce
--
       Clinton isn't perfect, but I like him a lot more than Dole.
            Please register to vote, and vote for Democrats.
Bruce Perens AB6YM          [email-masked]            http://www.hams.com/

---

From: [email-masked]
Date: Sat, 17 Aug 96 23:28 EDT

Bruce Perens writes:
  Bruce>  Let's plan on having "shadow" be part of the base for 1.2 . We
  Bruce> should thus have the default "login" be aware of it, etc.

Let's not forget about xdm, please.

--
Dirk Eddelb"uttel                             http://qed.econ.queensu.ca/~edd

---

From: Michael Meskes <[email-masked]>
Date: Sun, 18 Aug 1996 15:49:05 +0200 (MET DST)

> have the default "login" be aware of it, etc.

But the question remains, which login? The standard one patched, or the
shadow one, or both and the user decides?

Michael

-- 
Michael Meskes                   |    _____ ________ __  ____
[email-masked] |   / ___// ____/ // / / __ \___  __________
[email-masked]                  |   \__ \/ /_  / // /_/ /_/ / _ \/ ___/ ___/
[email-masked]                |  ___/ / __/ /__  __/\__, /  __/ /  (__  )
Use Debian Linux!                | /____/_/      /_/  /____/\___/_/  /____/

---

From: Richard Kaszeta <[email-masked]>
Date: Sun, 18 Aug 1996 11:16:10 -0500

>Cc: [email-masked] (Debian Development)
>
>Bruce Perens writes:
>> 

Quick question (which may show some of my ignorance of the current
linux shadow stuff):

Will inclusion of the 'shadow' package as default interfere with the
use of NIS passwd/group entries? Our installation is fairly dependent
on NIS.

-- 
Richard W Kaszeta 			Graduate Student/Sysadmin
[email-masked]			University of MN, ME Dept
http://www.menet.umn.edu/~kaszeta

---

From: Miquel van Smoorenburg <[email-masked]>
Date: Mon, 19 Aug 1996 10:14:59 +0200 (MET DST)

> use of NIS passwd/group entries? Our installation is fairly dependent

NIS and shadow don't interfere.

Mike.
-- 
  Miquel van    | Cistron Internet Services   --    Alphen aan den Rijn.
  Smoorenburg,  | mailto:[email-masked]          http://www.cistron.nl/
[email-masked] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)

---

From: Patrick Weemeeuw <[email-masked]>
Date: Tue, 20 Aug 1996 10:34:44 +0200

Date: Sun, 18 Aug 96 19:14 PDT
   From: [email-masked] (Bruce Perens)

	   Thanks

	   Bruce

Is this the final decision of the project leader, or is this issue
still open to discussion?

I have the feeling that an awful lot of work is being duplicated here.
All of the work being done to support shadow password files, will have
to be done over again to support PAM.  Also, IMHO the PAM framework is
superior, as it supports shadow password files among others (give or
take maybe a few options particular to the shadow package actually
used).

The big question is: is PAM ready for integration in the distribution?
RedHat surely thinks it is stable enough to make some applications PAM
aware.  I expect we can take the patches from RedHat, or at least use
their code as an example in case Debian uses other source code.  So we
should be able to support PAM in the same time frame as would be
needed to support shadow, at least for some authentication clients
(login, passwd, ...) and some underlying modules (e.g. unix & shadow).

Disclaimer: I am not a PAM expert, I simply monitor the PAM mailing
list to see how progress is made, and have put a Debian package
together with the PAM libraries and the underlying modules.  I also
appreciate very much the work already done on shadow support, but I
feel that these issues must be raised.

Patrick
--
    People who are doing things for fun do things the right way by
    themselves -- Linus Torvalds

---

From: Michael Meskes <[email-masked]>
Date: Tue, 20 Aug 1996 18:25:36 +0200 (MET DST)

> I have the feeling that an awful lot of work is being duplicated here.

But then almost the complete work has already been done.

> take maybe a few options particular to the shadow package actually

What exactly does it offer that shadow doesn't?

Michael

---

From: Patrick Weemeeuw <[email-masked]>
Date: Wed, 21 Aug 1996 11:12:00 +0200

From: Michael Meskes <[email-masked]>
   Date: Tue, 20 Aug 1996 18:25:36 +0200 (MET DST)
   [...]
   What exactly does it offer that shadow doesn't?

For general information, see http://www.redhat.com/linux-info/pam/
and for Linux-PAM: http://gluon.physics.ucla.edu/~morgan/pam/

But to answer your question in short: PAM (which stands for pluggable
authentication modules) is an API that encapsulates (hopefully) all
authentication methods.  As a consequence, an authentication client
using PAM does not need to be reengineered any more to be able to use
a new authentication method (e.g kerberos, s/key, id-cards...), but
the new authentication method must be coded once as a PAM module to be
available to all applications.

There are several kinds of modules, that can be transparently chained
together by PAM: e.g. for session logging, for granting/denying access
to a particular service based on the time of the day, tty, host; or to
log every single character the user types for the real paranoid
... you just name it (or implement it and plug it in :-).  Another
example: passwd can be configured via PAM to use some custom local
modules for extra password strength checking .

Currently PAM does support unix password files and shadow and some
other utility modules (and work is going on on s/key and kerberos),
which seems enough functionality to get started.

PAM is also a standard (DCE-RFC 86.0).

Patrick.

---

From: Michael Meskes <[email-masked]>
Date: Wed, 21 Aug 1996 12:37:35 +0200 (MET DST)

> and for Linux-PAM: http://gluon.physics.ucla.edu/~morgan/pam/

Got it. Thanks.

> ...

It seems it does not contain shadow completely, though.

Since the shadow transition is almost completed I wonder what we shoudl do
now.

Michael