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

    > And lo, Jochen Friedrich saith unto me:
    >> 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

    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
    Proprietor, Starshine Technical Services:
    PGP 1024/2ABF03B1 Jim Dennis <>
    Key fingerprint = 2524E3FEF0922A84 A27BDEDB38EBB95A

     \ /
      Last update: 2005-03-22 13:40    [W:0.020 / U:5.692 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site