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

>>> But everyone has been saying that it is *necessary* that a PAM module
>>> be run in the caller's address space; that this feature is required by
>>> real-world PAM modules.

>> Yes. But with screensavers, "the caller" isn't a screensaver, but the
>> wrapper program.

> 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?

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

>>> I did, and if it is correct that some PAM modules need to be able to
>>> change the state of the caller, then those PAM modules cannot be run
>>> under the setuid wrapper - they will not have access to the *actual*
>>> caller.

>> It seems you are misunderstanding here.
>> PAM modules need to able to change the state of the caller, if
>> it's called from programs like getty, ftpd, rlogind, rshd and telnetd.
>> But PAM modules don't have to change the state, if ti's called from
>> screensavers.

> 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.

>>> A radius server.

>> Thanks you.
>> And in that case, does BSD auth provides better security than PAM?
>> No.

> Yes, it does.  The radius database can be restricted in access such that
> a security hole in the radius server doesn't let you access the actual
> radius database.

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.

>> In a configuration that BSD auth doesn't need root setuid root
>> programs with a radius server, PAM doesn't need root privilege for
>> the raidus server configuration at all.
>> In a configuration that PAM needs root privilege with the radius server,
>> BSD auth does need its setuid root module, too.

> But the setuid module can be *a separate program*, keeping the root
> privileges restricted only to the moment of authentication.

> Or, indeed, it could be non-root.  You could have two user accounts:
> One runs the radius server, and nothing else, and has no access to
> anything anywhere.  One runs the radius database, and nothing else,
> and has access only to those files.  If you break a hole in the
> radius server, you still can't read the database.

You missed that just same technique (a separated program) can be used
with PAM, too, for the radius server case.
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.
So, that the difference, that there is only 1 setuid root progarm with 
PAM vs 6 extra setuid programs and 7 extra setgid programs with BSD
auth, remains with the non-privileged raidus server.
--
soda