Re: Locking a process or thread onto a specific CPU

D. Feuer (dfeuer@mail.his.com)
Fri, 19 Feb 1999 19:41:51 -0500 (EST)


Question: would it be advisable to add an atomic killuser system call to
kill all processes belonging to a certain user (and optionally blocking
any attempts to create processes owned by them), including, of course,
login shells? This would seem to be an excellent way to smash a really
bad user before they can do any harm, and also preventing them from
leaving any backdoors in place (cron scripts, cgi scripts, etc.).

David Feuer
dfeuer@his.com

On 19 Feb 1999, Zygo Blaxell wrote:

> In article <36CCDD25.FA25DEA7@by.net>, Mike Goldman <whig@by.net> wrote:
> >>>> Once in a while, a
> >>>> student would write a program that essentially forked in a loop
> >where
> >>>> the parent process exited. This kind of process is _hard_ to kill
> >>>> since neither is it visible using 'ps', nor is the PID constant. In
> >>>> IRIX, it is easy to solve this problem by disabling 3 CPUs [snip].
> >>>> In Linux, on a 4-way SMP system, you're stuck.
> >
> >>> Getting a little off topic, but you do not need to disable CPUs to
> >fix
> >>> that particular problem. Just get the process group id or session id
> >
> >>> (PGID or SID columns from ps xaj) and kill -9 -pgid or kill -9 -sid.
> >
> >> Consider the case where the process does a setsid() after fork(). The
> >
> >> problem doesn't go away.
> >
> >#!/bin/sh
> >#
> ># slay 1.2 - kill all processes belonging to the specified user(s).
> ># by Chris Ausbrooks <fish@bucket.ualr.edu>
> ># based on kall (a script of unknown origin)
> ># Please mail me any suggestions or corrections.
> ># Donations welcome.
> ># Changes by Pawel Wiecek <coven@debian.org>
>
> A long script, but it won't do the job either.
>
> Assuming the processes are all running under one userid, just do this:
>
> # su userid -c 'kill -9 -1'
>
> Assuming SysV-ish signal semantics, you'll kill every process that userID
> owns atomically (hmmm...well, maybe not atomically with multiple CPU's, but
> you can probably kill 'em faster than the other CPU's can fork 'em, so
> run kill(2) in a tight loop in a realtime process and you're all set. ;-).
>
> --
> Zygo Blaxell, Linux Engineer, Corel Corporation, zygob@corel.ca (work),
> zblaxell@furryterror.org (play). It's my opinion, I tell you! Mine! All MINE!
> Size of 'diff -Nurw [...] winehq corel' as of Fri Feb 19 03:14:00 EST 1999
> Lines/files: In 5201 / 28, Out 30657 / 391, Both 35527 / 395
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/