On Mon, 1 Sep 2003 kpneal@pobox.com wrote:

> On Thu, Aug 28, 2003 at 10:15:44AM -0700, Bill Studenmund wrote:
> > On Wed, 27 Aug 2003, Dan Melomedman wrote:
> > The reason it has to be loaded in the client app is that it is a
> > per-process entity. You are loading what that individual process can use
> > to access AFS. The cache is inherited across fork() AFAIK.
> I've actually thought about what it would take to get something similar
> to AFS auth but more general (and less gross -- no group list stuff) into
> the kernel. It would be useful for a process to be able to switch UID's
> back and forth without having to switch through the root account. What
> would it take to get something like this implemented?
>
> The more I thought about it the more complicated it became. IE, how would
> AFS PAG's be generalized? Would we end up with overlapping sets of PAGs?
> What would it mean to do a setpag() in that case? Would PAG management
> evolve into something that resembled a filesystem? Or, if we pass
> login:password into the kernel would the kernel have to call out to a
> program that was running? What if that program failed? How long before we
> have something that resembles MVS's RACF/ACF2/TopSecret programs (available
> from three different vendors), and is this good or bad? On and on.

Heh. Yes, something like a PAG is what I have in mind (w/o the group
hack). I'm not sure what all the details should be, but I don't think it
will end up looking like a file system. :-)

Take care,

Bill