Subject: Re: BSD Authentication
To: Simon J. Gerraty <email@example.com>
From: Greywolf <firstname.lastname@example.org>
Date: 08/27/2003 21:39:50
Thus spake Simon J. Gerraty ("SJG> ") sometime Today...
SJG> The more interesting aspect is the ability of radius and tacacs+ to
SJG> communicate arbitrary attributes back to the client. Typically you
SJG> then want a means of making these known to the real client process.
Isn't this just the sort of thing that secure ipc/rpc would be suited to?
If the stuff is, a la AFS, in kernel, wouldn't the authenticating process
do well to pass the process handle and resulting creds in via an ioctl()
(or something) of some sort? That way the calling process never needs to
see the cookies (since they're really only relevant in the kernel).
If the stuff is NOT handled in kernel (well, to a degree, all auth
will eventually tweak something in the kernel pertinent to [sre][ug]id/
glist), then the stuff comes back via secure ipc/rpc from the authenti-
cating process to the calling process (if the calling process has
described itself to be suitable to the task of modifying [sre][ug]id/glists).
[This is almost a good case for having an external means of setting the
[re][ug]id/glist of a process. Yes, yes -- I KNOW it looks fraught with
insecurity, but so is everything else that we take on anew. If it's done
correctly, it shouldn't be a problem. Sure, famous last words. I'm just
not gonna make everyone happy on this one, sorry.]
NetBSD: More Nines.