>>>>> On Mon, 08 Sep 2003 14:55:05 -0500,
	seebs@plethora.net (Peter Seebach) said:

>>> But then, in the cases where it's really the authentication client that
>>> needs to be eaccessible to the PAM module, this *won't work*.

>> Hmm, I cannot understand this sentence.
>> What do you mean here?

> I cannot see what is magic about screensavers.

The magic is that screensavers don't need to authorization.
The screensaver processes already have enough privilege,
what they just need to perform is authenticaion only.

>> With screensavers, the wrapper is the actual authentcaion client,
>> and there is no problem to access PAM module from the client.

> Okay.  So, why do you think this is allowable for screensavers, but not
> for any other kind of program?

As I said above, screensavers don't have to perform authorization.

> Why is it that login needs to actually
> be the authentication client, and PAM modules must have full access to
> login's address space, but for a screen saver, they suddenly don't need
> it?  Why can't login call this setuid wrapper program too?

Because /usr/bin/login performs authorization.

You can see that /usr/bin/login requires root privilege even on
OpenBSD. (it calls setusercontext(3)).

>>> Why is this?  Keep in mind, it might be peeking into the caller's
>>> state, not changing it.  Perhaps the PAM module needs to sneak a
>>> peak at some other data structure.

>> Because there is no such state in screensavers at all.

> Isn't that a question specific to each PAM module?

No.

>> Usually, if there is a security hole in a radius server, it's bad
>> enough. An intruder often can access the database by using the security
>> hole.
>> But, OK, if you really want to restrict access to the database with PAM,
>> you can implement the radius server by using privilege separation
>> technique with PAM. So, the radius process doesn't have to have the
>> privilege to access the database.

> And yet, you still come down to one of two cases:
> 1.  The access to the database happens in the radius server's address space.
> 2.  PAM modules which would require access to the server's address space
> to do things correctly won't work.

No.
The separated process doesn't have to access server's address space
with raidus server. Because radius server doesn't need to perform
authorization in the host.

>> You missed that just same technique (a separated program) can be used
>> with PAM, too, for the radius server case.

> So, for screensavers and radius servers, PAM can run just fine with
> separate programs.

> So when *DO* we need it to be a loadable module?

When we need to perform authorization.

>> Probably the same setuid wrapper program (for the screensaver) can be
>> used to implment the separate program for the raidus server, if we
>> design it carefully.

> In other words, this program is exactly equivalent to a BSD auth program
> which passes authentication on to other modules after giving them setuid.

Yes. You are right.
The difference is that this can provide complete compatibility with
existing third party PAM modules (and even compatibility with existing
BSD auth modules, too), in contrast that BSD auth framework cannot
provide the compatibility.
--
soda