|
|
| Author |
Message |
| 25 new of 80 responses total. |
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.
|
jazz
|
|
response 56 of 80:
|
Aug 25 12:17 UTC 1999 |
What gives with people creating recursively nested directories,
anyways? I've never seen them try that trick on any other system I've been
on.
|
darkskyz
|
|
response 57 of 80:
|
Aug 26 00:24 UTC 1999 |
i think that newer OSes have a limit on depth of nested directories, but i'm
not sure. if they do and the other systems you have been on are newer oses
then parhaps it simply isn't possible there. note this is just a hunch - i
don't have the time to look in the linux source code (which is several million
lines long) to check if i'm right about this.
|
mdw
|
|
response 58 of 80:
|
Aug 26 17:45 UTC 1999 |
I've seen people create deeply nested directories on m-net. This was on
the altos. I remember spending some time teaching the OS how to limit
directory nesting. It's not an entirely trivial problem to fix.
|
drew
|
|
response 59 of 80:
|
Aug 26 19:15 UTC 1999 |
You start out with a deeply nested directory, like /a/u/s/user.
Recursively nested - that would be like having a symbolic link to a few levels
up? I guess there's no harm in it, unless you run something that recursively
follows all subdirectories and treats links as actual directories.
|
mdw
|
|
response 60 of 80:
|
Aug 26 19:53 UTC 1999 |
/a/u/s/user is only 4 levels down, which hardly qualifies as deeply
nested. I have pathnames at work like
/afs/umich.edu/group/itd/build/mdw/krb5.cast/krb5/src/lib/crypto/des/afsstring2k
ey.c and even that's not too hairy; it does fit on one line, and is only 13
levels deep, at least. The directories created by the last vandal were over
3000 levels deep, and this was deep enough to cause problems for the "SYSAUDIT"
feature which we had inadvertently built into the grex kernel; this feature
collects path name information for C2 security logging purposes, and apparently
the feature didn't like pathnames over 64k in size. It seems, in some
respects, we operate in a more hostile environment than the pentagon.
|
don
|
|
response 61 of 80:
|
Aug 26 19:57 UTC 1999 |
Why dontya just modify the sysaudit program to spit out a message into the
sys log when there's a huge directory and skip it?
|
mdw
|
|
response 62 of 80:
|
Aug 26 20:07 UTC 1999 |
Because it's not a program, we don't have source to it, we don't need
it, and taking it out is effectively the same as having it skip every
directory.
|
steve
|
|
response 63 of 80:
|
Aug 26 22:47 UTC 1999 |
Actually, taking it out was a win. IN talking with someone at MSU today
who has dealt with C2 security stuff on SunOS, his comment was along the
lines that we ought to have crashed into C2 weirdness before now. So just
getting rid of it was a win.
|
mcnally
|
|
response 64 of 80:
|
Aug 27 01:17 UTC 1999 |
I get cognitive dissonance when someone talks about crash-preventing
measures as a "Win".. Too much Microsoft influence, I guess..
|
steve
|
|
response 65 of 80:
|
Aug 27 03:26 UTC 1999 |
Mike, when you administer a system like Grex, anything you can do to
stop the vandal from doing things is a "win". It's just one more item
that they can't use to hurt you. Now, granted this is similar to the
Microsoft style of software creation, but in Grex's case I think its
pretty reasonable.
|
scg
|
|
response 66 of 80:
|
Aug 27 03:37 UTC 1999 |
I think Mike was making a pun. Win as in Windows.
|
jazz
|
|
response 67 of 80:
|
Aug 27 12:10 UTC 1999 |
Heh.
Recursive-directory spam seems to be of the sort of low-brow attempted
hacking that'd be stopped with a few changes to mkdir.
|
steve
|
|
response 68 of 80:
|
Aug 27 14:05 UTC 1999 |
The changes need to be in the kernel, not mkdir. A vandal could
circumvent a protected mkdir program by simply calling mkdir in some
code. It can be done in the kernel, but it isn't a trivial task.
|
jazz
|
|
response 69 of 80:
|
Aug 27 15:18 UTC 1999 |
To truly prevent it, yes. I'm just saying that that sort of exploit
is in most cases used by someone who wouldn't *think* nor have the resources
to write even a simple chdir() mkdir() recursive program. Come to think of
it, most programmers I know aren't capable of really recursive programming,
heh. :P
|
mdw
|
|
response 70 of 80:
|
Aug 27 23:01 UTC 1999 |
This particular vandal used a perl script.
|
steve
|
|
response 71 of 80:
|
Aug 28 06:03 UTC 1999 |
At least 50% of the recursive dir bombs have been C code. The nastyist
one creates random strings of files and dirs, then dives another level
deep and starts over again.
Changing mkdir itself isn't worth it.
|
janc
|
|
response 72 of 80:
|
Aug 28 18:11 UTC 1999 |
Yup, most of the people who are stupid enough to want to do something
like this aren't smart enough to write even a shell script - they use
programs written by other people that they found on the web. Half of
them barely know what the programs they run do - except that it is
somethink K00l and hackerish. The programs themselves aren't typically
very good either, since they were mostly written by people who just
barely knew what they were doing, but they are very diverse. Building
good defenses against them is non-trivial. We finally have good
defenses against fork bombs, at least.
|
jazz
|
|
response 73 of 80:
|
Aug 29 11:37 UTC 1999 |
If there's something running around the script kids that does mkdir()
calls, then I retract my statement. I haven't seen one on any of the ususal
suspects.
|
flem
|
|
response 74 of 80:
|
Sep 16 16:00 UTC 1999 |
If you were writing a program whose only objective was to make really
deep directories, why would you recurse? I would think looping would
be far more effective.
|
