persistent process - Unix

This is a discussion on persistent process - Unix ; Hi! What do you think is the best way to kill this process: export a='((echo -n "export a='"'"'" echo -n "$a"|sed '"'"'s/'"'"'"'"'"'"'"'"'/&"&"&/g'"'"' echo "'"'"' $a")|sh) /dev/null 2>/dev/null&' echo "$a"|sh Many thanks! Stephen...

+ Reply to Thread
Results 1 to 20 of 20

Thread: persistent process

  1. persistent process

    Hi!

    What do you think is the best way to kill this process:

    export a='((echo -n "export a='"'"'"
    echo -n "$a"|sed '"'"'s/'"'"'"'"'"'"'"'"'/&"&"&/g'"'"'
    echo "'"'"'
    $a")|sh)/dev/null 2>/dev/null&'
    echo "$a"|sh

    Many thanks!

    Stephen

  2. Re: persistent process

    Stephen Westwood writes:

    > Hi!
    >
    > What do you think is the best way to kill this process:
    >
    > export a='((echo -n "export a='"'"'"
    > echo -n "$a"|sed '"'"'s/'"'"'"'"'"'"'"'"'/&"&"&/g'"'"'
    > echo "'"'"'
    > $a")|sh)/dev/null 2>/dev/null&'
    > echo "$a"|sh


    Set ulimit for number of processes to something low before dropping
    that fork bomb.

    Here's a smaller fork bomb:

    ){ :|:& };:

    --
    Måns Rullgård
    mans@mansr.com

  3. Re: persistent process

    On 2007-10-09, Måns Rullgård wrote:
    > Stephen Westwood writes:
    >
    >> Hi!
    >>
    >> What do you think is the best way to kill this process:
    >>
    >> export a='((echo -n "export a='"'"'"
    >> echo -n "$a"|sed '"'"'s/'"'"'"'"'"'"'"'"'/&"&"&/g'"'"'
    >> echo "'"'"'
    >> $a")|sh)/dev/null 2>/dev/null&'
    >> echo "$a"|sh

    >
    > Set ulimit for number of processes to something low before dropping
    > that fork bomb.


    In recent versions of bash, this is actually not a fork bomb. I did not
    try it in other shells, but with the & sign after 2>/dev/null it does not
    trigger ulimit, forever forking now processes and exiting the old. So
    there must be another way to get rid of the process.

    >
    > Here's a smaller fork bomb:
    >
    >){ :|:& };:
    >


    Yeah nice one.

  4. Re: persistent process

    Stephen Westwood writes:

    > On 2007-10-09, Måns Rullgård wrote:
    >> Stephen Westwood writes:
    >>
    >>> Hi!
    >>>
    >>> What do you think is the best way to kill this process:
    >>>
    >>> export a='((echo -n "export a='"'"'"
    >>> echo -n "$a"|sed '"'"'s/'"'"'"'"'"'"'"'"'/&"&"&/g'"'"'
    >>> echo "'"'"'
    >>> $a")|sh)/dev/null 2>/dev/null&'
    >>> echo "$a"|sh

    >>
    >> Set ulimit for number of processes to something low before dropping
    >> that fork bomb.

    >
    > In recent versions of bash, this is actually not a fork bomb. I did not
    > try it in other shells, but with the & sign after 2>/dev/null it does not
    > trigger ulimit, forever forking now processes and exiting the old. So
    > there must be another way to get rid of the process.


    I admit I didn't analyse it carefully. I just thought looked like it
    ought to be a fork bomb.

    If all it does is creating new processes, the old ones exiting, would
    a simple control-c not do the trick? If that fails, control-z should
    stop the process, allowing a SIGKILL to be sent at your leisure.

    --
    Måns Rullgård
    mans@mansr.com

  5. Re: persistent process

    On 2007-10-10, Måns Rullgård wrote:
    > Stephen Westwood writes:
    >
    >> On 2007-10-09, Måns Rullgård wrote:
    >>> Stephen Westwood writes:
    >>>
    >>>> Hi!
    >>>>
    >>>> What do you think is the best way to kill this process:
    >>>>
    >>>> export a='((echo -n "export a='"'"'"
    >>>> echo -n "$a"|sed '"'"'s/'"'"'"'"'"'"'"'"'/&"&"&/g'"'"'
    >>>> echo "'"'"'
    >>>> $a")|sh)/dev/null 2>/dev/null&'
    >>>> echo "$a"|sh
    >>>
    >>> Set ulimit for number of processes to something low before dropping
    >>> that fork bomb.

    >>
    >> In recent versions of bash, this is actually not a fork bomb. I did not
    >> try it in other shells, but with the & sign after 2>/dev/null it does not
    >> trigger ulimit, forever forking now processes and exiting the old. So
    >> there must be another way to get rid of the process.

    >
    > I admit I didn't analyse it carefully. I just thought looked like it
    > ought to be a fork bomb.
    >
    > If all it does is creating new processes, the old ones exiting, would
    > a simple control-c not do the trick? If that fails, control-z should
    > stop the process, allowing a SIGKILL to be sent at your leisure.
    >


    Won't work, either, as the process is running in the background, detached
    from the keyboard, after passing the first & sign. And it can't be fore-
    grounded because it is backgrounded from a sub-shell.

    If it's really that hard to get rid of the process, I'd regard that as a
    security problem, as the process succeeds to slow down other processes of
    lesser priority and doesn't even get listed by "top".

  6. Re: persistent process

    Stephen Westwood writes:

    > On 2007-10-10, Måns Rullgård wrote:
    >> Stephen Westwood writes:
    >>
    >>> On 2007-10-09, Måns Rullgård wrote:
    >>>> Stephen Westwood writes:
    >>>>
    >>>>> Hi!
    >>>>>
    >>>>> What do you think is the best way to kill this process:
    >>>>>
    >>>>> export a='((echo -n "export a='"'"'"
    >>>>> echo -n "$a"|sed '"'"'s/'"'"'"'"'"'"'"'"'/&"&"&/g'"'"'
    >>>>> echo "'"'"'
    >>>>> $a")|sh)/dev/null 2>/dev/null&'
    >>>>> echo "$a"|sh
    >>>>
    >>>> Set ulimit for number of processes to something low before dropping
    >>>> that fork bomb.
    >>>
    >>> In recent versions of bash, this is actually not a fork bomb. I did not
    >>> try it in other shells, but with the & sign after 2>/dev/null it does not
    >>> trigger ulimit, forever forking now processes and exiting the old. So
    >>> there must be another way to get rid of the process.

    >>
    >> I admit I didn't analyse it carefully. I just thought looked like it
    >> ought to be a fork bomb.
    >>
    >> If all it does is creating new processes, the old ones exiting, would
    >> a simple control-c not do the trick? If that fails, control-z should
    >> stop the process, allowing a SIGKILL to be sent at your leisure.
    >>

    >
    > Won't work, either, as the process is running in the background, detached
    > from the keyboard, after passing the first & sign. And it can't be fore-
    > grounded because it is backgrounded from a sub-shell.


    I think this bit of C code will have the same effect:

    #include
    #include

    int main(int argc, char **argv)
    {
    for(;
    if(fork())
    _exit(0);
    return 0;
    }

    Running this resulted in some difficult to kill processes. In fact, I
    can't think of a way to reliably get rid of them. Starting a few
    other processes all running infinite loops slowed the forking down
    enough that killall/pkill was able to kill them.

    > If it's really that hard to get rid of the process, I'd regard that as a
    > security problem, as the process succeeds to slow down other processes of
    > lesser priority and doesn't even get listed by "top".


    As long as this thing isn't running at the highest priority (and
    untrusted users shouldn't have access to that), it will always be
    possible to starve it with a higher-priority process which should
    allow it to be killed.

    If you think of a more reliable way, I'd be interested.

    --
    Måns Rullgård
    mans@mansr.com

  7. Re: persistent process

    M?ns Rullg?rd wrote:

    > As long as this thing isn't running at the highest priority (and
    > untrusted users shouldn't have access to that), it will always be
    > possible to starve it with a higher-priority process which should
    > allow it to be killed.
    >
    > If you think of a more reliable way, I'd be interested.


    Yeserday I came across a patch to FreeBSD's jail facility which would allow
    you to kill a jail (i.e. kill all processes in the jail).

    That's not a fair answer, though.

  8. persistent process

    MR> In fact, I can't think of a way to reliably get rid of them.

    killpg() is your friend.


  9. Re: persistent process

    J de Boyne Pollard wrote:
    > MR> In fact, I can't think of a way to reliably get rid of them.
    >
    > killpg() is your friend.


    Wouldn't then setsid() be your enemy in such hostile scenario?



  10. Re: persistent process

    On 2007-10-10, Måns Rullgård wrote:
    > Stephen Westwood writes:
    >
    >> On 2007-10-10, Måns Rullgård wrote:
    >>> Stephen Westwood writes:
    >>>
    >>>> On 2007-10-09, Måns Rullgård wrote:
    >>>>> Stephen Westwood writes:
    >>>>>
    >>>>>> Hi!
    >>>>>>
    >>>>>> What do you think is the best way to kill this process:
    >>>>>>
    >>>>>> export a='((echo -n "export a='"'"'"
    >>>>>> echo -n "$a"|sed '"'"'s/'"'"'"'"'"'"'"'"'/&"&"&/g'"'"'
    >>>>>> echo "'"'"'
    >>>>>> $a")|sh)/dev/null 2>/dev/null&'
    >>>>>> echo "$a"|sh
    >>>>>
    >>>>> Set ulimit for number of processes to something low before dropping
    >>>>> that fork bomb.
    >>>>
    >>>> In recent versions of bash, this is actually not a fork bomb. I did not
    >>>> try it in other shells, but with the & sign after 2>/dev/null it does not
    >>>> trigger ulimit, forever forking now processes and exiting the old. So
    >>>> there must be another way to get rid of the process.
    >>>
    >>> I admit I didn't analyse it carefully. I just thought looked like it
    >>> ought to be a fork bomb.
    >>>
    >>> If all it does is creating new processes, the old ones exiting, would
    >>> a simple control-c not do the trick? If that fails, control-z should
    >>> stop the process, allowing a SIGKILL to be sent at your leisure.
    >>>

    >>
    >> Won't work, either, as the process is running in the background, detached
    >> from the keyboard, after passing the first & sign. And it can't be fore-
    >> grounded because it is backgrounded from a sub-shell.

    >
    > I think this bit of C code will have the same effect:
    >
    > #include
    > #include
    >
    > int main(int argc, char **argv)
    > {
    > for(;
    > if(fork())
    > _exit(0);
    > return 0;
    > }
    >
    > Running this resulted in some difficult to kill processes. In fact, I
    > can't think of a way to reliably get rid of them. Starting a few
    > other processes all running infinite loops slowed the forking down
    > enough that killall/pkill was able to kill them.
    >
    >> If it's really that hard to get rid of the process, I'd regard that as a
    >> security problem, as the process succeeds to slow down other processes of
    >> lesser priority and doesn't even get listed by "top".

    >
    > As long as this thing isn't running at the highest priority (and
    > untrusted users shouldn't have access to that), it will always be
    > possible to starve it with a higher-priority process which should
    > allow it to be killed.
    >
    > If you think of a more reliable way, I'd be interested.
    >


    For a solution which doesn't depend on brute force, I suppose it is
    only possible by blocking the attack vectors of the program. In the
    case of your C version, this reduces to the fork() functionality of
    the kernel, so it probably won't be possible portably.

    I'm trying to write a proof of concept using kprobes for linux:

    sed sYXYY<detect-fork.c
    X#include
    X#include
    X#include
    X#include
    X#include
    X
    Xstatic struct task_struct *my_do_fork(struct task_struct *orig)
    X{
    X struct timespec now;
    X time_t difference;
    X do_posix_clock_monotonic_gettime(&now);
    X difference = now.tv_sec - current->start_time.tv_sec;
    X printk("%d forks after %ld seconds\n", current->pid, difference);
    X if (difference<1) {
    X printk("%d forking fast\n", current->pid);
    X /* penalize? */
    X }
    X jprobe_return();
    X /*NOTREACHED*/
    X return 0;
    X}
    X
    Xstatic struct jprobe my_jprobe = {
    X .entry = (kprobe_opcode_t *) my_do_fork
    X};
    X
    Xint init_module(void)
    X{
    X int ret;
    X my_jprobe.kp.symbol_name = "do_fork";
    X
    X if ((ret = register_jprobe(&my_jprobe)) <0) {
    X printk("register_jprobe failed, returned %d\n", ret);
    X return -1;
    X }
    X printk("Planted jprobe at %p, handler addr %p\n",
    X my_jprobe.kp.addr, my_jprobe.entry);
    X return 0;
    X}
    X
    Xvoid cleanup_module(void)
    X{
    X unregister_jprobe(&my_jprobe);
    X printk("jprobe unregistered\n");
    X}
    X
    XMODULE_LICENSE("GPL");
    Y

    Right now, it only detects the fast forking by measuring how long the
    processes live before forking. I thought about penalizing fast forking
    with a time delay, but I have yet to figure out how this is done
    (hints are appreciated). This would also have an impact on the whole
    system like the slowing down solution, but the impact will be
    concentrated on the fork-and-exit program. This one would have an O(n)
    penalty, while the worst case I can think of on a "normal" system
    would be shell scripts because they would fork off processes as a part
    of normal operation nearly always, but they would still only have an
    O(1) penalty, so I'd regard that as mostly reliable.

  11. Re: persistent process

    On 2007-10-10, William Ahern wrote:
    > M?ns Rullg?rd wrote:
    >
    >> As long as this thing isn't running at the highest priority (and
    >> untrusted users shouldn't have access to that), it will always be
    >> possible to starve it with a higher-priority process which should
    >> allow it to be killed.
    >>
    >> If you think of a more reliable way, I'd be interested.

    >
    > Yeserday I came across a patch to FreeBSD's jail facility which would allow
    > you to kill a jail (i.e. kill all processes in the jail).
    >
    > That's not a fair answer, though.


    Why is the answer not fair? The only problem with the answer is that
    it takes three preconditions which are probably not always met:
    1) Using FreeBSD
    2) having the patch installed
    3) having the process running in a jail

    But the answer could serve as a base for even better solutions.

    Under the assumption that the C version cannot be stopped reliably in
    a portable way (the shell script can be stopped by renaming /bin/sh
    for a short period of time), it could now be discussed what features
    a unix kernel should provide to conveniently fight such processes.

    Criteria could be:
    1) minimize impact on the rest of the system
    2) minimize preconditions
    3) implementability on a large set of kernels

  12. Re: persistent process

    On 2007-10-10, Måns Rullgård wrote:
    > Stephen Westwood writes:
    >
    >> On 2007-10-10, Måns Rullgård wrote:
    >>> Stephen Westwood writes:
    >>>
    >>>> On 2007-10-09, Måns Rullgård wrote:
    >>>>> Stephen Westwood writes:
    >>>>>
    >>>>>> Hi!
    >>>>>>
    >>>>>> What do you think is the best way to kill this process:
    >>>>>>
    >>>>>> export a='((echo -n "export a='"'"'"
    >>>>>> echo -n "$a"|sed '"'"'s/'"'"'"'"'"'"'"'"'/&"&"&/g'"'"'
    >>>>>> echo "'"'"'
    >>>>>> $a")|sh)/dev/null 2>/dev/null&'
    >>>>>> echo "$a"|sh
    >>>>>
    >>>>> Set ulimit for number of processes to something low before dropping
    >>>>> that fork bomb.
    >>>>
    >>>> In recent versions of bash, this is actually not a fork bomb. I did not
    >>>> try it in other shells, but with the & sign after 2>/dev/null it does not
    >>>> trigger ulimit, forever forking now processes and exiting the old. So
    >>>> there must be another way to get rid of the process.
    >>>
    >>> I admit I didn't analyse it carefully. I just thought looked like it
    >>> ought to be a fork bomb.
    >>>
    >>> If all it does is creating new processes, the old ones exiting, would
    >>> a simple control-c not do the trick? If that fails, control-z should
    >>> stop the process, allowing a SIGKILL to be sent at your leisure.
    >>>

    >>
    >> Won't work, either, as the process is running in the background, detached
    >> from the keyboard, after passing the first & sign. And it can't be fore-
    >> grounded because it is backgrounded from a sub-shell.

    >
    > I think this bit of C code will have the same effect:
    >
    > #include
    > #include
    >
    > int main(int argc, char **argv)
    > {
    > for(;
    > if(fork())
    > _exit(0);
    > return 0;
    > }
    >
    > Running this resulted in some difficult to kill processes. In fact, I
    > can't think of a way to reliably get rid of them. Starting a few
    > other processes all running infinite loops slowed the forking down
    > enough that killall/pkill was able to kill them.
    >
    >> If it's really that hard to get rid of the process, I'd regard that as a
    >> security problem, as the process succeeds to slow down other processes of
    >> lesser priority and doesn't even get listed by "top".

    >
    > As long as this thing isn't running at the highest priority (and
    > untrusted users shouldn't have access to that), it will always be
    > possible to starve it with a higher-priority process which should
    > allow it to be killed.
    >
    > If you think of a more reliable way, I'd be interested.
    >


    I realized that kernel patching isn't even necessary. The process can
    be stopped very easy on a SELinux box when the process type can be
    deduced somehow. Then it's just a matter of removing fork permission
    from that type for some short time.

    I realize that BSD folks will probably find this unfair either, as
    it's more flexible than the chroot thing and doesn't need a patch in
    recent Linux kernels. But I'm still interested if there is a portable
    solution.

    I think a portable, reliable solution would be a desirable thing.
    Think of ulimit, which is meant as a facility to prevent such things.
    It can limit process run time and number of processes, but I can't
    think of a way to use it for limiting this kind of process, so this
    way of writing a process could be thought of as a security hole in
    ulimit.

    On the other hand, if there is no portable way, this could serve as
    a nice test for managers to find out good administrators for hetero-
    genous unix networks: deploy the process via ssh on all the boxes
    and see on which unices he can manage to stop it

  13. persistent process

    SW> On the other hand, if there is no portable way, this could
    SW> serve as a nice test for managers to find out good
    SW> administrators for heterogenous unix networks: deploy
    SW> the process via ssh on all the boxes and see on which
    SW> unices he can manage to stop it

    Not really. As I wrote before: killpg() is your friend. The hardest
    part of your test is determining how to persuade each system's "ps"
    command to print out process group IDs. (Reading the manual page for
    "ps" was the part that took me the longest, at any rate.)


  14. Re: persistent process

    On Oct 22, 8:33 am, J de Boyne Pollard
    wrote:
    > SW> On the other hand, if there is no portable way, this could
    > SW> serve as a nice test for managers to find out good
    > SW> administrators for heterogenous unix networks: deploy
    > SW> the process via ssh on all the boxes and see on which
    > SW> unices he can manage to stop it
    >
    > Not really. As I wrote before: killpg() is your friend. The hardest
    > part of your test is determining how to persuade each system's "ps"
    > command to print out process group IDs. (Reading the manual page for
    > "ps" was the part that took me the longest, at any rate.)


    So try that on my version of the "fork machinegun":

    int main(void) {
    while (access("/tmp/ceasefire", F_OK) != 0) {
    pid_t pid = fork();
    if (pid > 0) {
    _exit(0);
    } else if (pid == 0) {
    if (setsid() < 0) {
    perror("setsid");
    }
    printf("Can't catch me, I'm PID %lu, PGID %lu, SID %lu\n",
    (unsigned long)getpid(),
    (unsigned long)getpgrp(),
    (unsigned long)getsid(0));
    } else {
    perror("fork");
    sched_yield(); /* give init a chance to reap zombies */
    }
    }
    printf("Bye!\n");
    return 0;
    }

    As a safety feature, you can touch /tmp/ceasefire to kill it if all
    else fails.


  15. persistent process

    MR> #include
    MR> #include
    MR>
    MR> int main(int argc, char **argv)
    MR> {
    MR> for(;
    MR> if(fork())
    MR> _exit(0);
    MR> return 0;
    MR> }

    SW> [...]
    SW> On the other hand, if there is no portable way, this could
    SW> serve as a nice test for managers to find out good
    SW> administrators for heterogenous unix networks: deploy
    SW> the process via ssh on all the boxes and see on which
    SW> unices he can manage to stop it

    JdeBP> Not really. As I wrote before: killpg() is your friend.
    JdeBP> The hardest part of your test is determining how to
    JdeBP> persuade each system's "ps" command to print out
    JdeBP> process group IDs. (Reading the manual page for
    JdeBP> "ps" was the part that took me the longest, at any
    JdeBP> rate.)

    f> So try that on my version of the "fork machinegun":

    Control-Q (or whatever your terminal's stop character happens to be)
    is your friend for that one. As, indeed, is a pipe.


  16. Re: persistent process

    On Oct 24, 8:38 am, J de Boyne Pollard
    wrote:
    > f> So try that on my version of the "fork machinegun":
    >
    > Control-Q (or whatever your terminal's stop character happens to be)
    > is your friend for that one. As, indeed, is a pipe.


    You're thinking of Control-S. Okay, fine, but take out the printfs
    and perrors and try again. I put them in for demonstration purposes
    but of course an evil user wouldn't have them.

    I don't know what you mean by a pipe. The user running this program
    is evil and not going to direct the output in a way that makes it
    convenient to get rid of. Just the contrary.

    killall may work, if you are lucky enough that the machinegun doesn't
    run in between when killall searches the process table and when it
    issues the signal. You'd probably want to kill all processes owned by
    the user, since with a little more cleverness we could have the
    process name constantly change.



  17. Re: persistent process

    fjblurt@yahoo.com writes:
    >On Oct 24, 8:38 am, J de Boyne Pollard
    >wrote:
    >> f> So try that on my version of the "fork machinegun":
    >>
    >> Control-Q (or whatever your terminal's stop character happens to be)
    >> is your friend for that one. As, indeed, is a pipe.

    >
    >You're thinking of Control-S. Okay, fine, but take out the printfs
    >and perrors and try again. I put them in for demonstration purposes
    >but of course an evil user wouldn't have them.
    >
    >I don't know what you mean by a pipe. The user running this program
    >is evil and not going to direct the output in a way that makes it
    >convenient to get rid of. Just the contrary.
    >
    >killall may work, if you are lucky enough that the machinegun doesn't
    >run in between when killall searches the process table and when it
    >issues the signal. You'd probably want to kill all processes owned by
    >the user, since with a little more cleverness we could have the
    >process name constantly change.
    >


    Any system which allowed untrustworthy users and didn't limit NCHILD
    with a system-wide ulimit to a reasonable value (e.g. 20) deserves
    what they get.

    A properly configured system will shrug off your 'fork machinegun'.

    Note that redhat, for example, configures the default ulimit -u value
    to 16382, which is way too large for a timesharing system.

    scott

  18. Re: persistent process

    scott@slp53.sl.home (Scott Lurndal) writes:

    > fjblurt@yahoo.com writes:
    >>On Oct 24, 8:38 am, J de Boyne Pollard
    >>wrote:
    >>> f> So try that on my version of the "fork machinegun":
    >>>
    >>> Control-Q (or whatever your terminal's stop character happens to be)
    >>> is your friend for that one. As, indeed, is a pipe.

    >>
    >>You're thinking of Control-S. Okay, fine, but take out the printfs
    >>and perrors and try again. I put them in for demonstration purposes
    >>but of course an evil user wouldn't have them.
    >>
    >>I don't know what you mean by a pipe. The user running this program
    >>is evil and not going to direct the output in a way that makes it
    >>convenient to get rid of. Just the contrary.
    >>
    >>killall may work, if you are lucky enough that the machinegun doesn't
    >>run in between when killall searches the process table and when it
    >>issues the signal. You'd probably want to kill all processes owned by
    >>the user, since with a little more cleverness we could have the
    >>process name constantly change.

    >
    > Any system which allowed untrustworthy users and didn't limit NCHILD
    > with a system-wide ulimit to a reasonable value (e.g. 20) deserves
    > what they get.


    No ulimit settings will help here since there are only a handful of
    processes at any one time.

    > A properly configured system will shrug off your 'fork machinegun'.


    Please describe "properly configured".

    --
    Måns Rullgård
    mans@mansr.com

  19. persistent process

    f> So try that on my version of the "fork machinegun":

    JdeBP> Control-Q (or whatever your terminal's stop character happens
    JdeBP> to be) is your friend for that one. As, indeed, is a pipe.

    f> You're thinking of Control-S.

    Actually, I wasn't. Control-S is bash's forward history search, for
    me. I _meant to write_ Control-S, but when I noticed that I'd written
    Control-Q I decided to let it stand, to emphasize the point made in
    the parentheses.

    f> Okay, fine, but take out the printfs and perrors and try again.
    f> I put them in for demonstration purposes but of course an
    f> evil user wouldn't have them.

    An _evil_ user would incorporate some sort of diabolical payload,
    though. And that's in part the point. Once one has the program doing
    more than solely fork()ing, more ways to stop it appear.

    " su ${EVILUSER} -c "kill -STOP -1" " is your friend for your new
    program, by the way.


  20. Re: persistent process

    On Oct 26, 6:01 am, J de Boyne Pollard
    wrote:
    > f> So try that on my version of the "fork machinegun":
    > " su ${EVILUSER} -c "kill -STOP -1" " is your friend for your new
    > program, by the way.


    Aha, that's the ticket. And "kill -1" is atomic, so no possibility
    for a race. Thanks, this had been nagging at me.


+ Reply to Thread