Re: suidpid( UID, credential? ) ? secure IPC?

kwrohrer@enteract.com
Mon, 6 Oct 1997 06:48:28 -0500 (CDT)

And lo, Jochen Friedrich saith unto me:
> kwrohrer@enteract.com wrote:
> > And lo, Jim Dennis saith unto me:
> > > I was wondering if there is any mechanism for having some
> > > process (a daemon or kernel module perhaps) "touch" a process
> > > and set its *real* UID to a different value.
> > Probably not.
> >
> > > Would it make sense to add a suidpid() call?
> > What happens if, after authentication, the process dies and another
> > process pops up with the same PID? Hard to do nowadays, but I don't
> > believe it's guaranteed impossible, especially given some way of
> > bogging the authenticator down at the right moment...
>
> I donīt see this problem when the kernel handles this problem:
> - program calls kernel seteuid_auth(authinfo)
If you're going to do this, either you've got to make some special new
kernel-to-user communication system, or you may as well make the
authenticator a kernel module.

> - kernel blocks program and passes authinfo to authenticator
A normal blocked process is quite killable. If, on the other
hand, you arrange for temporary immortality, you'd better arrange
to revoke it at some point if the authenticator is missing or
confused. *Somebody* has to handle errors, and if the kernel
has to detect them and unimmortalize the process...

> - authenticator verifies authinfo and passes back status
Ah, you did intend a brand new communication method after all.
Again, better to have a module, or have the authentication
request be fully userspace. Much simpler and more robust,
and like I said it's not easy to kill a process and get the
same PID quickly...

> - kernel changes euid (or responds with error) of program
> - kernel releases program.
>
> A process canīt be killed while it is blocked in the kernel.
You don't want to allow this if you can possibly avoid it.
Unkillable processes are bad(TM)! Even if they're not doing
anything but cosmetically increasing the load average and taking
up a PID. There are some things (e.g. stock 2.1.57's lockd)
which accidentally get into this state, but I can't think of
anything but init that can't (or, at least, shouldn't) be
killable in a properly working UN*X environment.

> The kernel would need to check the authenticator and i.e. signal
> init if the authenticator dies.
You want not only a new system call, but a new communication method,
a new task for init, and error checking for all of the above? A
larger hammer will not help with pounding in this particular screw,
IMHO...

Keith