Greywolf wrote:
> Thus spake Dan Melomedman ("DM> ") sometime Today...
> 
> DM> I am not an AFS expert, but there's more than one way to pass data
> DM> between the kernel and the userland. Also is there some convoluted
> DM> reason why credential cache for AFS should be in the kernel? It does
> DM> sound like an incredibly bad design decision; and Unix has seen quite a
> DM> few incompetent misuses of its flexibility over the years - PAM included.
> 
> To jump on the other side of the fence:
> 
> "Is there some convoluted reason why things like process uid, gid,
> ruid, rgid, svuid and svgid and the glist should be kept in the kernel?"

> [Boy, I feel *really* sheepish about this considering I just suggested
> an external way of manipulating the above credentials on a random
> process.]
> 
> But I think the idea is that if it's in the kernel, you do reduce
> the ability to modify it in userland.

Why not just have a dedicated credential cache process in a chroot
jail? How much easier would it be to modify/steal them? Have a clean
interface between it and the authenticators/kernel like a socket
/dev/blah and getpeerid(), and presto.