On Tue, Sep 09, 2003 at 02:21:46AM +0900, Noriyuki Soda wrote:
> >>>>> On Mon, 8 Sep 2003 18:59:58 +0200,
> 	Joerg Sonnenberger <joerg@britannica.bec.de> said:
> 
> > First of all, BSD auth does not need any additional priviledges by itself.
> > Just those needed for the authenticator. Therefore login, xlock and the
> > like _never_ need to be setuid root for the purpose of authentication.
> 
> I think this argument about /usr/bin/login is not fair.
> Certainly OpenBSD's /usr/bin/login isn't setuid root, but it lacks a
> feature that traditional /usr/bin/login has.
> If we don't need the traditional feature (changing user id),
> /usr/bin/login doesn't have to be setuid root with PAM, either,
> because most programs which invoke /usr/bin/login already has root
> privilege.

That's part of the problem. Login will not work with a PAM module
which needs access to /etc/master.passwd if it not running as root.
Let's just drop the question of how root/shadow/... right are achieved,
the fact remains that login and xlock need to run at least partly as
root to use a PAM module for local authentication. 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.

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.

BSD auth itself is not more secure, but it allows a better isolation
and separation of priviledges and that leads to a more secure
framework.

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

Well, those are the most important questions from a marketing
point of view.

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

That's a very difficult question. I think it is possible to support
most PAM modules of the "auth" and "password" class. I have no idea
about "account", but I suppose much of that can be emulated with the
nsswitch layer. The "session" class is IMHO very difficult to
emulate. What is it used for? Is it really usable in a generic
framework? Things like pam_motd are quite useless without support
from the calling application e.g. in xdm.

> > 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 ;-))
and that is the perhaps the most important use of third party modules.

Joerg

> --
> soda
> 
>