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

Jim Dennis (jimd@starshine.org)
Tue, 07 Oct 1997 15:43:49 -0700


> 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.

I figured this might be the case and asked if there was
any existing kernel/process IPC mechanism that would
suffice.

Perhaps we need ways of "registering" and querying a set of
"kernel services."

Could it be done as a device driver? A feature of the
proc filesystem?

>>
>> 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.

I agree. However, the kernel can maintain the list
of "locked PID's" -- and "unlock" that PID as soon as
the "auth" request is cancelled.

>
>> 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

Then please describe a screwdriver that will fit its head and
give us the required torque.

--
Jim Dennis  (800) 938-4078		consulting@starshine.org
Proprietor, Starshine Technical Services:  http://www.starshine.org
        PGP  1024/2ABF03B1 Jim Dennis <jim@starshine.org>
        Key fingerprint =  2524E3FEF0922A84  A27BDEDB38EBB95A