|
|
| Author |
Message |
| 25 new of 175 responses total. |
steve
|
|
response 115 of 175:
| 
Dec 15 11:59 UTC 1998 |
We were graced with a self-replicating life form last night.
(a fork bomb) ;-)
|
gregb
|
|
response 116 of 175:
|
Dec 15 13:53 UTC 1998 |
What is a "fork bomb?"
|
steve
|
|
response 117 of 175:
|
Dec 15 14:27 UTC 1998 |
A fork bomb is a program that makes infinite copies of itself.
It's "children" then start running and start spawning copies of
themselves, and before long (like less than a minute) most machines
will become completely preoccupied with running the fork bomb and
nothing else gets done.
Grex is in a little better shape. When someone runs a fork bomb
here, they can't use up all the resources, so Grex doesn't die--it
just becomes disgustingly slow, but things can still be done.
|
rcurl
|
|
response 118 of 175:
|
Dec 15 15:32 UTC 1998 |
Is the bomb run in just one directory or, if not, is it disseminated
among many? (That is, if telling won't compromise the system.....)
|
mjb
|
|
response 119 of 175:
|
Dec 15 16:51 UTC 1998 |
Um, not sure what you mean by that exactly. A fork bomb is a trivially
simple C program, (no, I'm not going to post one here) that is initiated
by a single user, and just starts filling process slots. The idea is
that it's a program that makes copies of itself. Consider the implication.
If it's a program that makes copies of itself, what do the copies do? Well,
they makes copies of themselves. On a system that has no safeguards in
place, it will bring a system to it's knees in short order. I'm not root
here, so I don't know what safeguards steve implied in #117, but I'd guess
it would be something to do with limiting how many processes a user can
have running. If this is unlimited (as it is by default on many systems)
then a fork bomb is devastating, and usually a reboot at the console is
your only recourse. If you limit the number of processes a user can have,
then the fork bomb will replicate till it fills the process space allocated
to the user (perhaps 16 or 32 processes) and then those will eat CPU, but
not enough of the CPU will be consumed to render the system useless. That
way, a root-type can still login, kill all the fork bombs, and get the system
back to normal. It's interesting to note that many kernels (like BSD that
m-net runs) there is one process slot reserved for root. That means that
when the system is topped out, root keeps one process in it's back pocket.
Of course, if a root person can't even 'su' to root cause he can't get a
process slot allocated, then that extra process doesn't do much good. ;-)
|
rcurl
|
|
response 120 of 175:
|
Dec 15 16:55 UTC 1998 |
You answered my question - the processes all belong to one user so the
codes are all in one directory. What is the limit on processes one
user can have at one time?
|
steve
|
|
response 121 of 175:
|
Dec 15 16:59 UTC 1998 |
People write them in their own directories or in /tmp, compile
them and then run 'em. It's a trivial, trival thing to write, so
simple that even the dullest vandal can simply type it in rather
than FTP it.
|
mcnally
|
|
response 122 of 175:
|
Dec 15 18:19 UTC 1998 |
I think #118, #120 probably indicate that Rane's confused by some of
the usage used in other recent responses.. There's no *file* copying
going on in a runaway fork program. There's just one copy of the
program in the filespace which gets run over and over and over. It's
the copying in *memory* (to hold multiple simultaneous invocations of
the same program) that's so resource-consuming.
|
gregb
|
|
response 123 of 175:
|
Dec 15 18:40 UTC 1998 |
How do you know--if there is a way to know--how many process to allocate a
user?
|
steve
|
|
response 124 of 175:
|
Dec 15 19:18 UTC 1998 |
I'm not sure I understand your question, but you can use the ps program
to see how many proceses are owned by whom, which is one way to spot
strange activity.
|
mjb
|
|
response 125 of 175:
|
Dec 15 19:30 UTC 1998 |
Re #124: Steve, I'm afraid I might be responsible for some of the latest
confusion. In my previous response I stated that I didn't know what
security measure grex uses in combating fork bombs, but I suggested that
it may be a kernel limit on total number of simultaneous processes that
a user can execute. That was speculation on my part, and now people are
asking you questions about an unverified comment that I made. Sorry! ;-)
|
steve
|
|
response 126 of 175:
|
Dec 15 19:37 UTC 1998 |
Ah, I see. No, thats OK. Yes, we limit the number of processes that
any user can have running at once. Thats what makes forkbombs merely
nasty, rather then devistating.
|
gregb
|
|
response 127 of 175:
|
Dec 15 19:55 UTC 1998 |
That's what I was asking: How do you know how many proc. to limit a user?
Is it an arbitrary number?
|
steve
|
|
response 128 of 175:
|
Dec 15 20:29 UTC 1998 |
Well, in the world of the UNIX kernel nothing is arbitrary. The
default value was originally something fairly large, which isn't needed
in the environment of Grex where people don't do much at once. We
changed the figure to 100 procs per logged in entity. Actually, we
should likely go down form there but we'll have to experiement with
that.
|
mjb
|
|
response 129 of 175:
|
Dec 15 21:27 UTC 1998 |
Hmm...I was poking around a little while ago and I found:
#define MAXUPRC 25 /* max processes per user */
in both /usr/include/sys/param.h and /usr/kvm/sys/sys/param.h
so, perhaps it's 25, and not 100? Or perhaps I don't have a clue?
That's possible too...;-)
|
mcnally
|
|
response 130 of 175:
|
Dec 15 22:32 UTC 1998 |
re #127: Yes, basically you pick a number and the kernel returns an
error to any user program that tries to fork the n+1th process
for that user. It's not hard to pick a number that's on the
generous side of what a typical grex user would need during a
login session and still below the "one person can make the
system totally useless" threshhold.
|
tpryan
|
|
response 131 of 175:
|
Dec 15 22:45 UTC 1998 |
Did this come from the fork bomb factory (ISP) that Grex
blocked recently? or has that not been a problem these days?
|
kaplan
|
|
response 132 of 175:
|
Dec 16 03:16 UTC 1998 |
Do the backtalk designers read this item? If many different users are all
trying to run backtalk at the same time, all of the backtalk processes would
be owned by the same system account, right? So if this MAXUPRC limit is
reached, does backtalk (or the web server) handle that situation in stride?
Has it been tested? Just a thought....
|
steve
|
|
response 133 of 175:
|
Dec 16 04:17 UTC 1998 |
Nope, the limit is 100. It was changed in the object itself;
one of the things we need to do is gen a new kernel with the
right value.
No, the last fork bomb did not come from anywhere that I've
ever seen before. I'm in contact with the right people on that
one.
|
mdw
|
|
response 134 of 175:
|
Dec 16 07:31 UTC 1998 |
The real limit for the # of user runnable processes is set by the
variable "maxuprc" in /vmunix. This is set in param.c to default to
MAXUPRC, but can be set to some other value. We set it to 64 (so the
limit is actually 64 not 100). While we *could* have built param.c to
have a different value, I think we *actually* used adb to patch /vmunix
directly.
|
davel
|
|
response 135 of 175:
|
Dec 16 13:02 UTC 1998 |
Maybe STeve was counting in octal?
8-{)]
|
steve
|
|
response 136 of 175:
|
Dec 16 13:06 UTC 1998 |
No, that was my memory, based on reading email from some time
ago. Hmm. 64hex is 100decimal, so that may be it.
|
remmers
|
|
response 137 of 175:
|
Dec 16 13:07 UTC 1998 |
Result of the Grex Board Election:
---------------------------------
Voting members (these are the ones that count):
9 dpc
33 janc
12 mziemba
18 other
30 remmers
23 steve
Non-members (unofficial):
1 cmcgee (withdrew her candidacy)
15 dpc
34 janc
23 mziemba
26 other
36 remmers
35 steve
Since there were three slots to fill, janc, remmers, and steve are
elected to 2-year terms.
|
jep
|
|
response 138 of 175:
|
Dec 16 13:17 UTC 1998 |
Congratulations to the new Board members!
Thanks to everyone who ran. It's wonderful to be able to choose from
such an excellent ballot. This was a no-lose election, with 7 great
candidates.
|
janc
|
|
response 139 of 175:
|
Dec 16 16:39 UTC 1998 |
Cool. Thanks to all those who supported me.
Looking at these results, I find myself simultaneously pleased that
John and Steve got elected, and regretting that some of the other, very
able people without so long a Grex history didn't get elected.
Obviously we need to increase the size of the board. The only way I
could find to vote for all the other candidates I really wanted to see
on the board was by not voting for myself. Oh well. Thanks so much to
those who ran but didn't get elected. I respect your devotion to Grex
and your willingness to help.
|
