Re^2: A (highly) "ethical" use for for Perl

[blazar]

read directly the code to find what it does:

Why are you wasting our time with a code submission if you aren't going to describe it? I don't know what it is and I don't know why should I care! I'm not going to waste my time figuring it out, and I'm sure as hell not going to run the code on my machine when it seems like its some sort of DDoser.

I sincerely apologize: had I known the consequences of this post of mine I would have never ever submitted it.

I thought that the code would have been both (fundamentally) self explanatory and also kinda funny because of the expressive names given to variables and subs.

However you're right: it's some sort of DoSer, but for quite a relaxed meaning of the term. In fact it does NOT do DoS, "only" it puts the machine under heavy load iff a condition is realized, precisely that a certain user is logged.

As was implicitly implied, it would be natural to consider this "project" unethical rather than ethical as stated... however let me explain: this particular user is an unbearable arrogant idiot.

I could exhibit tons of anecdotes to support the claim above, and I'm sure that in the end you would fundamentally agree with me. However I fear that this would be OT here.

For those who want to know, this program sits down sleeping most of the time checking who is locked on the machine it's running on. If all the users are "bad", then it starts an harassing phase by forking 127 copies of itself each of which will basically just do rand() all of the time. The original copy continues to check who is logged and if the harassing condition does not hold any more (e.g. a "normal" user logs in) then it kills all the harassing copies and turns back to the "waiting in the shadow" phase.

[davido]

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 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.

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.

Your post sparked a big debate between at least one of the Janitors and an individual who believed the post should be reaped. Frankly, if it had been considered for reaping due to malicious or dangerous content, rather than for being useless, it probably would have been reaped. We don't reap for uselessness, but we do for posts that are dangerous.

[blazar]

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.

[jryan]

Alright, that's cool, but why didn't you post that to begin with? I immediately caught what you meant by "ethical", and I immediately saw what the program did. I can't possibly fathom why the node approver didn't see that.

Anything suspected to be malicious does NOT go over well here. In the olden days, a thread like this would have been nuked - that means it wouldn't even go under the normal review process to be deleted, with a record of it remaining. The admins would make it just *disappear*. Its happened to me before, a few years ago over what I thought was some innocent networking code. (This node wasn't deleted under the normal review process because I was pretty sarcastic in my consideration - I often forget that people here don't get sarcasm. It kind of sucks for you, the rep would have probably wouldn't have gone under a -5 if it had been reaped.

Anyways, the quality of the code isn't too shabby. Lurk a bit, and don't try to imply that you're some sort of cracker next time, ok? :)

[tye]

Then next time don't consider it with a reason of "useless". "Useless" doesn't tell me anything bad about a node. It tells me that the person considering the node could not think of much good about it but also was at a loss to actually describe anything bad about it.

And the person doing the considering is the one who must take the most care in evaluating what should be done. So if the considerer can't come up with any offense beyond "useless", my first reaction is to want to remove the consideration. When I investigated this one, I saw a reply from the considerer and it just emphasized the "useless" angle and went on to claim to not even know what the code did. So voting "keep" was an easy choice for me since "deleting" should require "harm".

[jryan]

You know, it sounds like our consideration system is really, really, really broken.

[blazar]

Alright, that's cool, but why didn't you post that to begin with? I immediately caught what you meant by "ethical", and I immediately saw what the program did. I can't possibly fathom why the node approver didn't see that.

As I already wrote, I thought in fact that it was self-explanatory. And (IMO) funny because of the sarcasm, and FWIW, not really malicious...

Anything suspected to be malicious does NOT go over well here.
<SNIP>
was some innocent networking code. (This node wasn't deleted under the normal review process because I was pretty sarcastic in my consideration - I often forget that people here don't get sarcasm. It kind of sucks for you, the rep would have probably wouldn't have gone under a -5 if it had been reaped.

Well, as hinted above this is not really malicious. It's a kind of joke: of course this thing won't run forever. We only do want to see his reaction, but we do not want to do any harm to him: the sysadmins could have done much worse things, had they really wanted.

All in all I'm still astonished at the kind of feedback I got: indeed I'm used to think of a Perl-addict as a person with a great sense of humor, so it definitely surprises me that people don't get sarcasm here. Also because in other Perl-related contexts it seems to me that they definitely do: for example in clpmisc, where the sarcasm of some of the most resourceful regulars is often mistaken for harshness towards newbies...

Anyways, the quality of the code isn't too shabby. Lurk a bit, and don't try to imply that you're some sort of cracker next time, ok? :)

Indeed I will. However at the cost of being repetitive, I'd like to stress that it didn't seem to me so harmful after all. Well, definitely it isn't! And OTOH what's more important, I think it's fundamentally well written (although there's certainly room for improvements) but even more importantly it was a strong motivation for me to learn better about message handling and process management techniques.