One flaw with your strategy is that if 127 forks causes enough of a slowdown, other users may be unable to log in at all, thus the DOS criteria would never be broken, and the machine would forever stay in DOS mode (as long as the baddies are logged in). This problem would be

Nope! (or fundamentally Nope!) At this point I must ask you to trust me on my word: indeed I was stupid enough to post this without being 100% sure it would have been accepted positively, but not enough to run the beast without previously testing it. And I assure that it has always behaved well in all tests, even when it had to "behave bad"...

Actually the machine during the harassing phase is heavily slowed down, but I wouldn't call it "DOS mode" since no service is actually ever denied. Users indeed can still log in: of course it takes a few seconds (an average of 5, I'd say) and it takes a few seconds to kill all the rebel childs too, but it definitely does not last forever.

I can only imagine of something going wrong if for any reason there are already too many processes running (highly unlikely). At that point the machine will first or later be blocked in a real DoSish state for no further process could be even possibly be forked (yes: our cluster is currently vulnerable to this kind of attack.)

But then you'll notice that I included an emergencyexit() sub that will make any instance of the process die immediately as soon as it will find a 'STOP' entry in my home. Since homes are mounted over nfs this can be done on any node: to be fair I'm not sure if this will work with a machine with the process table already filled up, but at least it should be clear that I provided a relatively easy way to stop the whole damned thing and this should make clear that the program is definitely not as harmful as some of you (naively IMHO) assumed.

accentuated if a system cron job suddenly started the weekly backup to DVD-ROM or tape drive (or whatever) at the same time that the DOS mode was active. The combination of the two heavy loads would bring the server to its knees to the point that the only hope would be rebooting.

This won't happen! I admit that I skipped over quite a load of details: this is a cluster of diskless pc's (well, most of them do have a disk, but they're "diskless" anyway). Users cannot login into the server: when they connect from outside they're bounced on one of the clients.

All administration jobs are done on the server. On each client machine the heaviest thing that can be running at any time can be some X app or a numerical simulation.

If the person operating the server has a problem with some of its users, perhaps he (the system adminstrator) could set some policies that either restrict their bad behavior, or that make the place no fun for baddies. Once the policy is violated, there'll be legitimate reason to show them the one way exit door. In other words, he should grow a backbone and not ask one of his other users to sabbotage his system as a childish expression of disapproval of one or more of its users.

Well, ragarding certain issues there are no precise rules, but implicit behavioural rules out of good sense, and he's "kind of" violated them. He's never done something really illegal: the point is that most of us definitely can't stand him as a person. But we're offering this service mostly on a volountering basis irregardless of personal preferences and we already have many users we don not appreciate under the human point of view. But we're not nazis, so even if sometimes phrases like "Couldn't there be random filesystem errors erasing data from this man's home?" have occasionally been heard, no one has ever done anything along these lines.

Also, the sysadmins have not asked me to "sabotage" their system. It was an idea of mine out of a personal question with this person. I asked them for approval making sure that I wouldn't have harmed the cluster per se and certainly no other user.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.