|
|
| Author |
Message |
| 25 new of 80 responses total. |
eeyore
|
|
response 31 of 80:
| 
Aug 9 02:02 UTC 1999 |
Okey....I'm happy then. :)
|
jshafer
|
|
response 32 of 80:
|
Aug 10 00:01 UTC 1999 |
(And my resp:30 showed up all on one line when I entered it...)
|
remmers
|
|
response 33 of 80:
|
Aug 13 02:25 UTC 1999 |
An online vote to rescind the board action referenced in resp:7 is now
underway. See Item 114 in the Coop conference for discussion. To cast a
ballot, telnet or dial direct to Grex and type 'vote' at a Unix shell
prompt or '!vote' at any other prompt. The polls are open through the
end of the day (EST) on Sunday, August 22.
|
steve
|
|
response 34 of 80:
|
Aug 14 04:01 UTC 1999 |
Grex was down for several hours (about 5pm to 11:30pm) Friday.
A system file had its contents changed, and was writable to the
world. This is of course Not Good and for a little bit I thought
we'd had a real security breach, and took Grex down.
This is of course the thing that all staff fear the most, that
someone has figured out some new way of getting into the system
and becoming root. There haven't been many times that I've thought
that this might have happened, but this was one of those times...
As it turns out, the file in question had the wrong permissions
because of the way the system booted up, and although we specified
a certain mode for the permissions (read only to the world) dear
old SunOS had a different idea. We took out the code that caused
this to happen, and all is well now.
Also tonight was the testing of a new method of dealing with
fork bombs, which is faster than previous forkbomb control--this
one should kill forkbombs nearly instantly. We tested it a bit
and its now running.
|
ktirkey
|
|
response 35 of 80:
|
Aug 14 15:18 UTC 1999 |
text
help
a:
a text
|
otaking
|
|
response 36 of 80:
|
Aug 14 15:55 UTC 1999 |
Re #34: What the heck are fork bombs?
|
steve
|
|
response 37 of 80:
|
Aug 14 17:03 UTC 1999 |
Forking is the term used when a running program splits itself into two
running programs. This is often done when a program wants to run another,
for example. Forking is a good thing. However, a runaway forking program
is a monster, creating endless copies of itself and ultimately clogging
the operating system by hundreds of copies of itself, to the detrement of
the rest of the system.
A forkbomb is a very small program which does nothing but fork itself
so very quickly the compter is doing nothing but dealing with all these
tiny little programs whose idea of a god time is to replicate. Think of
them as software tribbles and you have a good model.
The new anti fork-bomb code deals with this kind of problem very quickly.
|
mcnally
|
|
response 38 of 80:
|
Aug 14 18:26 UTC 1999 |
I prefer to think of them as process-table cancer, though the "software
tribbles" analogy works, too..
|
mdw
|
|
response 39 of 80:
|
Aug 15 01:59 UTC 1999 |
You can look at "insan3" for a typical example of a fork bomber.
|
steve
|
|
response 40 of 80:
|
Aug 15 08:33 UTC 1999 |
PTC! I love it! Thanks, Mike...
|
otaking
|
|
response 41 of 80:
|
Aug 15 20:47 UTC 1999 |
Thanks for the explanation Steve.
|
darkskyz
|
|
response 42 of 80:
|
Aug 16 01:24 UTC 1999 |
then why isn't he kicked out?
also, could you hack GCC to refuse compiling programs that are plainly fork
bombs?
for those of you wondering about the bombs, here's one courtsy of insan3
main()
{
while (1)
fork() ;
}
simple as that.
btw, i was wondering if the fork-bomb killer is available to download in
source? i might be interested to run one on my comp...
|
jazz
|
|
response 43 of 80:
|
Aug 16 02:13 UTC 1999 |
Always admired Berkeley for developing an elegant solution to
fork-bombs.
|
mdw
|
|
response 44 of 80:
|
Aug 16 03:37 UTC 1999 |
"safefork" doesn't come from Berkeley. It will probably appear in the
grex staff notes in due course. We'd like to make sure it's toilet
trained before releasing it into the wild.
"Disabling" a fork bomber doesn't work because it's probably a throwaway
account, and because we don't do any form of account validation to
enforce "uniqueness". For many of our users (indians, for instance)
proving "uniqueness" would be difficult. What we've historically done
instead, is to complain to the ISP. This is actually generally fairly
effective, because running a fork bomb is in fact illegal and nobody on
the internet wants to harbour criminals. On the other hand, it's a
terribly time consuming process for us, because we have to comb through
our records and construct a detailed report on the vandal, send e-mail
out, &etc.
|
jazz
|
|
response 45 of 80:
|
Aug 16 15:31 UTC 1999 |
No, I'm assuming you folks are using tools of the homegrown variety.
I was thinking of Berkeley's process accounting and control.
|
other
|
|
response 46 of 80:
|
Aug 18 13:09 UTC 1999 |
under what governing body is fork-bombing illegal? if it is the US,
then how does it apply to a foreign user? I'm curious about this...
|
scg
|
|
response 47 of 80:
|
Aug 18 17:39 UTC 1999 |
It certainly is in the US, as crashing a computer falls under various Federal
computer vandalism statutes (the one a lawyer told me about a few years ago
was, "unauthorized destruction of data," which included data held in a
computer's memory). The situation in other countries presumably depends on
the other country, although I would assume that damaging a computer in the
US from another country is probably illegal under US law.
|
steve
|
|
response 48 of 80:
|
Aug 18 19:39 UTC 1999 |
MIchigan has a law about interfering with the proper operation of a
computer. Thus I would imagine that the fork bomb would fall under
this law. Certainly they're disrupting enough.
We've had one vandal try this, twice. I guess the first time was
enough of a shock that it wanted to see if it was really real. ;-)
|
remmers
|
|
response 49 of 80:
|
Aug 22 12:41 UTC 1999 |
Today, Sunday August 23, is the last day to vote on the proposal
described in resp:33 . The polls will close at midnight (EDT).
|
remmers
|
|
response 50 of 80:
|
Aug 22 18:08 UTC 1999 |
Oops, slight correction - make that Sunday August 22 that the polls
close. (It's still today, but I had the date wrong.)
|
remmers
|
|
response 51 of 80:
|
Aug 23 13:19 UTC 1999 |
The proposal was defeated: 16 yes votes, 27 no. (The totals are slightly
unofficial, pending any changes in the membership roles in the last
month, but there wouldn't have been enough changes to affect the
outcome.)
Unofficial non-member votes: 67 yes, 74 no. Same outcome, although the
vote was closer.
|
remmers
|
|
response 52 of 80:
|
Aug 23 16:28 UTC 1999 |
Grex Board of Directors meeting tonight, Monday August 23, at Zingermans
Next Door, 422 Detroit Street, Ann Arbor. See item 119 in the Coop
conference for the agenda.
|
jiffer
|
|
response 53 of 80:
|
Aug 23 16:38 UTC 1999 |
is there a time?
|
remmers
|
|
response 54 of 80:
|
Aug 23 16:49 UTC 1999 |
Oh, whenever everybody gets there... :)
Oops, forgot to list the time. 7:00 p.m. Thanks for noticing.
|
steve
|
|
response 55 of 80:
|
Aug 24 22:31 UTC 1999 |
Grex was down today for a reboot, which turned out to be more compilcated
than
usual.
For the last two days the system has been running slower than normal,
because
of a program we ran to get rid of some vandal droppings, namely deeply nested
directories. Due to various problems deep inside the kernel the program
couldn't finish and we had a couple of them hanging in this strange state,
using resources.
Seeing that the problem was still here today, I rebooted the system. Unlike
most occaisons where I've rebooted remotely, this one couldn't be done without
human intervention. Thanks to Marcus for getting over and finishing the
cleaning job from the vandal's droppings.
|
