lkml.org 
[lkml]   [1997]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: suidpid( UID, credential? ) ? secure IPC?
Date
From

> 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



\
 
 \ /
  Last update: 2005-03-22 13:40    [from the cache]
©2003-2011 Jasper Spaans