pam + privileges

[Darren J Moffat]

On Wed, 30 Apr 2003, Frank Cusack wrote:

> On Wed, Apr 30, 2003 at 09:55:06PM +1000, Damien Miller wrote:
> > Whether pam_session should run with root is a matter of debate though.
>
> I'm surprised this is still a matter of debate.  pam_session needs
> to run as root!

I don't see what is to debate here either.

All pam_* functions assume that they are running with sufficient
priveleges for all potential modules to do their job.  This means that
all pam_* functions need to run as root or with some other definition
of all priveleges.

As it happens some modules on some systems don't need a lot (or in some
cases any) privlege do to their job.  However some modules need to update
or read files or access resources that need root privelege.
Note that while it is very impolite for PAM modules to change the uid/gid
of the process some do attempt to do this (sadly).

Calling any pam_*() function from libpam without suffcient privelege.
(euid=root in most systems) is a bug in the application.

Note also that some vendors have shipped versions of a pam_unix.so
authentication system that uses a setuid helper program in the implementation
of pam_sm_authenticate(3pam) to allow reading of /etc/shadow for the users
own encrypted password.  This confuses the issue for many developers of
PAM applications and is a disservice to PAM.  I believe the goal was to
allow screenlock type programs to re-authenticate the user, however a
screen lock should also be calling pam_setcred(pamh, PAM_REFRESH_CRED) which
is likely to fail on many configurations if the calling application is
not running as root.

--
Darren J Moffat