[ On Thursday, September 26, 2002 at 12:01:45 (-0400), Ken Hornstein wrote: ]
> Subject: Re: PAM 
>
> >Yeah, but the important part is that his sec_login_set_context() call
> >affects the parent process, thus allowing for "pluggability" through
> >exec() of a separate (possibly static linked and possibly setuid)
> >binary.  Done right it seems to me that the call to setpag() and even
> >the exec of the klog authenticator would be hidden in the nsswitch
> >callbacks done via libc in the ultimate parent of the PAG.
> 
> You didn't really read his document, did you?  sec_login_set_context() isn't
> the problem; setpag() is.  In AFS, and Doug and Robert's proposals today,
> you NEED to call setpag() in the parent.  Hence, you need to modify your
> initial authentication program, or you need something like PAM that can
> call a system call in the parent's address space.

You didn't really read what I wrote above it seems.  Either that or
perhaps you have some hidden agenda which you are not sharing.  As I say
above the setpag() (and the exec of the child process) would be done in
the callbacks registered with the wrapper API that hides all this goo
from the application.  This idea is very simple and elegant.  No
applications need to be modified to introduce any arbitrary system calls
or any other arbitrary code to the application asking for authorisation.
You don't even need the child process support, but of course if you want
to have the code which checks the authentication run with separate
privileges then you will....

I think your PAM blinders are still keeping you from seeing better and
ultimately more flexible solutions.

Runtime object code plugability can be added to something like BSD-Auth
or even a fleshed out nsswitch (just UTSL to see the intent along these
lines in the design in the NetBSD implementation).  However PAM cannot
(at least not easily) be hacked to avoid runtime object code loading.  QED.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>