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    [W:0.039 / U:0.104 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site