In message <200309081948.h88JmDq19088@srapc342.sra.co.jp>, Noriyuki Soda writes
:
>>>>>> On Mon, 08 Sep 2003 14:32:35 -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.

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

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

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

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.

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

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

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

No problem, we just write a /usr/libexec/login_setuid which is setuid, and
is used to call other methods with the privs they need.

It's ugly, yes, but it's just as ugly when you propose doing it with PAM,
and it lets us win the meaningless statistic "fewest setuid programs".

-s