(My last post on this topic).

>> >Douglas Engert has also implemented some interesting ideas in this area:
>> >
>> >	http://www.ornl.gov/~jar/dfs-afs.html
>> 
>> But, unfortunately, Doug was only interested in getting DFS back
>> to the same level of functionality that AFS had.  From that document:
>
>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.

Now ... yes, I _could_ modify AFS so that setpag() or some variant of
it modified the parent's process.  The security implications of this
are ...  well, "interesting" to say the least.  But let's pretend I
could even invest the time necessary to define such an interface which
had all of the security problems fixed (which, DESPITE YOUR REPEATED
CLAIMS, DOES NOT EXIST ANYWHERE TODAY!).  Am I going to do it?  No,
because I think PAM is probably a reasonable solution to this problem,
and I'd rather invest my time in something which has a hope of
reusability.  I don't think PAM is perhaps the best solution, but it's
at least a step in the right direction, and enough other people support it
that I can leverage some of this work.

Now, I know YOU don't like PAM ... but, let's face it.  You're a nut
who thinks the pinnacle of Unix happened in 1981, dyanmic ANYTHING is a
Tool of the Devil, and anyone who wants to do renaming in CVS needs
serious psychological counciling.

--Ken