>>>>> 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 is different from PAM, where every application must be able to deal
> with the set-bits just in case.

This is not true, either.
Do /usr/libexec/ftpd, /usr/libexec/rshd, /usr/libexec/rlogind and
/usr/libexec/telnetd has the setuid bit? No.
Most of programs which need to call PAM don't have to be setuid root,
because they *already* has root privilege.

Only programs which need the setuid bit with PAM is programs like
xlock. And for those programs, we only need one setuid wrapper which
call PAM to check the password. And if we have the wrapper, xlock and
programs like it don't have to have the setuid bit.
Thus, about the number of setuid programs, PAM only need one setuid
root program (for the wrapper), and BSD auth need 6 extra setuid and 7
extra setgid programs.

BTW, do you agree with the following my argument?
PAM module?
> 1. We need PAM anyway, for compatibility with other UNIX.
> 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.
--
soda