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.

Originally, I thought about AFS and the way it handled creds, and
I thought, Hm, what a hack.

Then I heard about NFSv4:  FS Credentials are no longer integers
or arrays thereof, they are strings indicative of user@dom.ain,
and the like, in the interest, so I've heard, of making NFS less
Unix-centric.  Those, IIUC, are going to live server-side -- you
guessed it -- in the kernel.

[unless some serious hashing and quick {,de}compression is happening,
 this has the potential to slow things down and/or bloat the hell
 out of the kernel space _at runtime_.]

				--*greywolf;
--
NetBSD: Stable and strong!