>>>>> On Mon, 8 Sep 2003 19:50:38 +0200,
	Joerg Sonnenberger <joerg@britannica.bec.de> said:

> the fact remains that login and xlock need to run at least partly as
> root to use a PAM module for local authentication.

Sorry, this objection doesn't make sense for me.
/usr/bin/login doesn't need the setuid-ness at all with PAM just like
BSD auth, if we don't need the traditional feature.
And /usr/bin/login still has the root privilege even with BSD auth,
if it's called from network daemons.

So, it's unfair to refer /usr/bin/login as an example of the
difference between PAM and BSD auth.

> The same is
> true for /usr/libexec/ftpd and all the others. The difference between
> BSD auth and PAM can therefore be reduced to whether the authentication
> scheme needs enough rights for every possible configuration or not.
> BSD auth can handle it independently on a per-authenticator base
> without any change of its caller. PAM can't.

I think this point is what BSD auth made mistake.
BSD auth assumes it is important to avoid root privilege from
programs which perform authenticaion. But actually it isn't,
most programs which perform authenticaion also need authorization
as I refered to ftpd, rlogind, rshd and telnetd.
Thus, the merit of BSD auth is very minor.

One major exception of this is xlock (as I said at the first place),
but it's easy to fix the problem (by the wrapper).

> Providing a setuid-wrapper around xlock or other programs which
> want to validate against /etc/master.passwd helps against one
> class of security faults by establishing a well-known environment,
> but a bug in xlock if run as root is still catastrophic. Teaching
> xlock to drop its priviledges would help, but that is exactly what
> PAM was ment to avoid.

What do you mean here?
If we have the setuid-wrapper, xlock doesn't have to be run as root.
So, there is not catastorphy at all.

>> BTW, do you agree with the following my argument?

>> > 1. We need PAM anyway, for compatibility with other UNIX.

> The "session" class is IMHO very difficult to emulate. What is it
> used for? Is it really usable in a generic framework?

If it isn't needed at all, why does it exist?
There are users' requirements that BSD auth cannot satisfy.

>> > 2. If we implement PAM over BSD auth, some third party PAM modules
>> >   may stop working, because some PAM modules may require the feature
>> >   that they can change the state of the caller process.
>> > 3. Thus, we have to implement PAM as a basic feature (and implement
>> >   BSD auth over PAM, if BSD auth compatibility is needed), instead
>> >   of vice versa.

> The third point is the simple solution. But which third party modules
> do we want to support which do need to change the calling process?
> For authentication module this is mostly avoidable (skipping AFS ;-))

Why do you skip AFS here? It seems there are number of people who are
still using AFS.
Also, do you have any concrete reason that AFS is the only module
which requires to change the state of the calling process?
I don't see such reason.
--
soda