Re: write with cURL

Tim Greer wrote:
Jerry Stuckle wrote:

Tim Greer wrote:
Jerry Stuckle wrote:


To justify $200 worth? Forgive me if I find that suspicious. We're
not talking about a customized service here and security should be
done across all users equally, unless you plan to either allow a
specific user to do more or to lock them down more than someone else
(neither would be appropriate in this case for this example, but
neither would
matter, which is the point I was intended to prove). Of course,
it's all for nothing if I'm unable to prove it to you.

Yep. That's a big discount - my normal minimum rate is over twice
that.

I didn't ask you to develop a site, so apparently it takes you an hour
plus to simply set up a basic account and type a single line of text in
shell. Really, you can stop making excuses.


Part of Jerrys' security is not letting you on his server... you haven't figured that out yet.

I need to account for the paperwork, etc., also. It takes time to
set
up an account for you, process the billing, etc.

Uh huh, sure.

When everything is considered, it's easily a couple of hours of work -
and still a discount from my equivalent hourly rate.

Whatever.

And no, my time is the only thing I have to sell, and I'm not
going to spend the time manually setting up a site without getting
paid, and it's not a $3.95 bargain basement account.
Who said it had to be only $3.95? What about $20 for 5 minutes of
your
time? That's cheaper than the bottom site development price of
$200
when you equate the hours spent. The fact is, the development
costs
have nothing to do with it. I repeatedly said I'd understand if
you
just didn't feel comfortable. You insisted it was because you
needed to use your pricing structure for full site development and
hosting (all just to create a basic account for something that
would take a couple of minutes).

And yes, I do control who has access to my servers.

....as he just stated. Security measure #1.

Obviously.

With my customers
I have a contract, and if they do anything to harm the servers, I
have legal redress.
That's fine, so why didn't you say that before? Why not say that
originally? I could totally understand it. You said that you'd
set up
an account only if I paid you. I said I would. Then it was $200,
and now it's to protect your clients.

Not that any of them would - I pick my customers
carefully, also, and don't let just anyone on the servers.

....and again, but you still don't get it.

That's all fine.

And yes, I understand what you explained to me on the phone. But
the first step requires access the users don't have - so the rest
of it is immaterial.
If you think it requires some special access or absolutely anything
a user couldn't do in any type of hosting or shared system
environment, then you didn't understand what I had explained.

Yes, I did understand, and on my servers they can't do step 1. It
doesn't require "special access" - but it does require access they
don't have.
There are ways to do "step 1", but that was just an example of one
method to get there. There are many ways to do the same thing, that
was just one I covered quickly on the phone. Also, what happens when
they upload a binary for the command or use another method (which is
easy enough to do). You then have to try and take further measures
to
prevent that. Eventually, you're left without CGI, PHP or SSI, or
otherwise have to run it in a way that no shared host could run.

There is no need to execute binaries on a web site,

Doesn't have to be a binary, that was one example. You think you can
restrict an upload binary on an account that you allow to run
executables, do you?


Jerry said he doesn't have that kind of access enabled by default. He also states (somewhere else) that if they (customers) do require that functionality he is going to investigate first. Security measure #2.

so I have restricted
them from setting the execute bit on a file.

I guess some people have to resort to trying to do stuff like remove all
possible features from a web site to make up for the security issues.


.... no just limit until (proved) needed.

Since they can't execute it (if they want to execute a PHP or Perl script, I give them the
command to access the interpreter), there's no problem. As well as
other ways you can think of.

Okay, Jerry, if you say so. It's unfortunate to see that you think this
type of thing actually stops security issues. It's even more
unfortunate, that while talking about a shared hosting environment, you
are just now starting to explain that you've disabled a great number of
things that are common (which wouldn't be a threat to security if you
just used a different setup). If your clients are fine with that, it
doesn't matter. However, you can't very well speak in terms of what is
secure on a shared server or not, when you're talking about a unique
setup that has a ridiculous amount of restrictions. Even still, the
most unfortunate thing, is that none of those things are going to
prevent the exploit methods you are still open to when it's all said
and done, and all because you wish to believe your method is "just as
secure" as methods it's clearly not as secure (considering you have to
disable so many things to try and get to the same point of security). Like I said, eventually, if you continue with that method, if you truly
want a secure system, you're going to have to go to such lengths that
CGI, PHP and SSI are not available to your users (and that's not much
of a hosting provider).

That's okay, I'm not being paid by you to secure your servers, and
I'm certainly not interested in paying you $200 to help you secure
your own
servers. In fact, I've never said your servers were horribly
secured, and just said that if a user of yours was malicious or had
their account taken over by a malicious user, then the Apache group
idea would open the potential for that malicious user to exploit
that setup to read and write to other people's files.

Sorry, my servers are secure.
No need to apologize. You're welcome to believe it, and that's fine.
My offer was to prove to you what you said I was wrong about and your
accusations that I didn't know what *I* was doing.

More is quoted and replied to below.

Nothing you have told me shows me you know how to lock down a server
so
that it is secure - other than to use the server's file security. There are other ways, but you won't admit to them.

Right, so you're back to acting like I have no idea what I'm doing,
because you don't understand the subject and there's no way to discuss
a matter with someone with that mindset. I offered to prove it and you
went to great lengths to avoid being proven wrong. Anyway, of course
there are other methods, and of course you don't want to just only rely
on permission settings. My point was that your method to go to such
lengths to avoid using such a basis is where you are creating a lot of
your own problems. Clearly, the one I suggested as a basis is superior
and my offer to prove it still stands.


Now, if you know and trust your users, it's unlikely that will be a
risk, provided no malicious users gain access to their account or
to
the server in another way. Really, in the end, just saying you're
not comfortable doing it, don't have a server free of non paying
clients you'd feel okay about using, or want to protect yourself in
a legal aspect, then that's fine.
....

<snip - stop quoting the replies so poorly, by quoting emails, usenet
postings and 4 posts in one reply>

Dear Jerry Stuckle,

Regarding the usenet thread where you've agreed to allow me to
prove
that your PHP setup is potentially not secure from user's reading
each other's files using PHP, you've stated that I would have to pay
for an account.
This is fine. Please let me know the price for your lowest priced
shared hosting account and I will promptly remit payment. Please
also let me know the methods of payment avilable (such as paypal, or
a merchant interface).
By accepting this, you agree that I am allowed to test the security
of your PHP install, and cause any damages or access any data that
would be against state or federal laws, and that this is simply to
illustrate that your PHP setup would allow one user on one account to
use PHP to access a file readable by the web server's user/group on
another, seperate account.
Therefore, if you can ensure that you have some test setup with a
temporary user or your own, and not for one of your normal shared
hosting users, that would be best. I remind you that I'm not
interested in accessing any other data or doing anything malicious on
your server, but to example how your PHP setup is not as secure as
you believe it to be.
Thank you,
Tim Greer


Tim,

The problem is, you assume the user has the ability to create a
symlink.

No, that is just one way to get there. And, what happens when
someone uploads a binary for ln (I assume you have it disabled or
removed or a jailed environment where they can't use that system ln
command and
don't have it where they can just alias it) and then run it? You
plan
to deny execution by not allowing executables? What's the deal then?
Are you saying your server is secure because you modify the sites and
the clients don't have access to log in and upload their own or
create
their own? If so, then it really doesn't speak in any great amount
to say it's secure because you restrict or don't allow your clients
to do
normal and common things. Besides, this does illustrate the point
that if you were a normal shared host that offered clients the
ability toe create symbolic links (and why not in general?), that you
would then be open to that security risk.

Remember - this is WEB hosting.

And it sounds like you're getting as far away from actually hosting as
possible in your examples and server setups.

Binary executables are not required on
a web site.

Nothing at all is required if you get down to it. It's about the
features and choices the clients have. This doesn't have to relate to
binaries at all. You can't stop a binary from running is the point. I'm sure you think you can, but you can't, not when you allow CGI and
PHP (and maybe SSI). Besides, some people have precompiled binaries
for CGI and there's nothing wrong with that (it's faster than an
interpreter).


And no one has requested the ability to upload a binary executable,

So? But you're not a web host. You don't offer shared hosting like a
real web host. You lock down the system and remove features that most
users want and that some users need (and should be able to, and have
the option without it posing some danger to the system's security).

I would be very leery anyway.

If I used your server setup, I'd be worried about it, too... among
dozens of other things (not to mention things you apparently aren't
aware of, since you don't realize your efforts are in vain). These
trivial methods you've using aren't going to prevent a problem, but
it's a poor design if they pose a problem (which is the point). More
to the point, is the topic of this thread and how your methods aren't
relevant or valid to the subject when you are basically prechecking
everything and not allowing a lot of features.

Even if I had them in their own jail, I don't know what they might be using the server to do.

To host their web site, upload files, sell things, whatever they'd
normally do.

But I would find out what they want to execute and why - and then make a
decision. However, no one has ever asked that, which doesn't surprise
me at all.


....here it is.

And if you ran a successful business and were actually a real web host,
you'd know that you can't look at every user's code, and if you were a
real admin, you'd know you can't stop executables if you allow
executables on the user's site. If you offer mod_php and disable
execution, fine, but you certainly don't allow Perl then as you said
earlier, and all bets are off when you allow PHP anyway.
Since you don't allow symbolic links to be created, you believe the
problem is nonexistent. Two problems exist with that theory. First,
there are other ways (this was just one quick example), and secondly,
more importantly, this wouldn't exist as an issue where users can set
the permissions on their files lower to deny other's from viewing
them or writing to them (symlinks or not). So, this does prove
there's a
difference, and a pretty vital one. Surely, if having the ability to
use symbolic links on a server opens such a big security problem,
then
you must admit that it's not as secure. If you think it's "as
secure" by removing the ability to do a bunch of things, that's one
way to see the problem, but it's more involved than just having the
ability to use and create symbolic links.

No, I don't say it's a big security problem.

But on your system, if users could create symbolic links, it _would_
open a big security problem. The fact is, they can use other methods
to create them as well, so again, attempts in vain.

But it's not necessary for them to have that privilege.

So what? It's not good that you hve to disable such an otherwise
harmless and useful feature to protect your server, instead of just
properly securing it and not having to sweat the small (otherwise
harmless) stuff.

I never said there is no difference

You said your method is just as secure.

- don't put words in my mouth.

- because that's YOUR job.

I did say that I had secure servers.

Yes, you did say that.


You keep trying to tell me ways that the server can be compromised -
believe me, I learned about every one of those - over 15 years ago.

I don't believe you. You have repeatedly illustrated that you lack
knowledge in this area, and it's proven by the fact that you claim your
method of securing the server is just as good as you can do simply with
suPHP and lower permissions (it's not). You have needed to disable
common and useful tools in an attempt to try and prevent it. I'm even
betting you didn't disable ln until I mentioned the issue earlier
(though far be it from you to admit it, so I'll just continue to
believe that).
the difference is I know how to secure a web server without depending
on CGI - something you claim is impossible.

I didn't say it was impossible (I never did). I said your method
doesn't achieve the same results (because you had described your method
and I know better). It doesn't have to relate to CGI, but the method
you use is futile.


But you really don't know.

You say so. You say a lot of things. You're too much of a coward to
face the facts and have someone prove it, which explains why you
sounded to nervous on the phone when I made you face it. Now, you're
here on usenet, your trolling home and you're just working your way
back to the normal you, where you will arrogantly claim this or that
and argue away. In the meantime, I reiterate that I offered you a real
chance to finally be able to prove what you say on usenet out of your
arrogance, and you flip flopped around like a politician and you're
already starting to misrepresent what happened or what was said, or who
said what. You're like some type of uber special troll. yeah, I get
it, no matter WHAT, in any medium or no matter what some one shows you
or proves or genuinely offers, there is no being right when you
disagree with that person. Facts and logic be damned. Right, I get
it. I've seen this from you for a very long time on usenet. We take
it off usenet and you back down from the challenge because you're so
worried about winning your argument, that you'd rather remain ignorant,
stubborn and arrogant and just fight with people. Fine.


But that's not possible on my systems - I have ln and certain
other
commands restricted so they can't be used.
Doesn't matter though. Obviously different systems can try different
things to achieve the same results regarding security, but at some
point, sometimes one of those methods is less secure and less
desirable. Again, your method is better than world write, but it's
not
as secure as suPHP. There's nothing wrong with realizing or seeing
that. Perhaps you can manage to really take away a bunch of common
commands and features and hope no one could easily get around them
(and they can so long as you allow CGI and PHP since they don't have
to use
"ln") and you have the same problem anyway. That just doesn't sound
like a good, sound balance to me.

Yep, and running PHP as a CGI is less desirable.

In your opinion, though I've outlined several compelling reasons why it
is beneficial for control, tracking, security and so on.

And you can claim it's less secure than suPHP,

I know it is.

but you really don't know

Actually, I _really do_ know. You just denying the facts and saying I
don't know, doesn't mean squat.

- because you are
making assumptions about my security that you don't know.

No, I'm replying to the very details you have been providing. You might
be an old man, but you're clearly new to server admin and security. No
reason to be embarrassed, I don't do web design because I suck at it,
but you also don't see me arguing with people that know more about web
design layouts in graphics or HTML groups, challenge them and then back
down when I know I'll be exposed for being a complete fraudulent
egomaniac.

Or, you are just saying anything not done YOUR way is not as secure.

Of course I'm not saying that. I said that the way you have configured
your server isn't as secure.

You really don't know, Tim.

I really do, Jerry.

You don't know my capabilities;

And you don't know mine, but you seemed quite comfortable and confident
that you could accuse me of not being a good server admin and didn't
know about security earlier in this thread. I'm basing my opinion on
my experience with you and your poor attitude and ego. I'm basing most
of it on the fact that you said just HOW you run the web server, which
indeed opens the security risks I've outlined. If i can't base my
opinion on what you've said yourself about your setup, then what can I
base it on? Why did you challenge me to prove it to you, then say I
had to pay to get an account on your server to prove it, and then say I
had to pay $200 for you to add an account for me to show you, and then
say you didn't want to do it because you have a legal contract with
your clients to protect their data, and then come back and start
challenging me again?

you don't know my system;

I know what you've said in this thread about your system.

you don't know my security setup.

I know what you've said in this thread about your security setup.

So you really can't say it's less secure.

I know it's less secure based on what you've said in this thread. I
know it's less secure, because you have had to resort to disabling
common tools and features that should be safe to run, because you know
(now) that they would pose a security issue on your system, because of
how you set up your system. Once again, you can say this or that, and
continue like you always do on usenet and troll away, or you can
actually be a man and stop being so arrogant and let me show you on
your system, like you said you would earlier, and then found every
excuse not to so you didn't have to face being proven wrong.

So your idea of using a symlink to map the directory into the user's
web
space doesn't work.
But it does. You're saying it doesn't, because the users can't
create a
symlink, but what if they could? They can still do it, after all.
However, let's just forget entirely about that one single example I
quickly rattled off about, since it was just one of many ways to get
to that point.

What if pigs could fly?

You'd be able to sell your car? Wait, do you have a car?

They can't, so any further discussion on the point moot.

That's the problem, you try and add some variable to "they can't, so
it's a moot point". It is NOT a moot point when they CAN via other
means. It is NOT a moot point when you claim your method is just as
secure and claim I just don't know (acting like I have nothing to base
my opinion on), yet you have to disable freaking symlink abilities,
because otherwise it would open your system up to a huge security
issue. Ironically, it's still possible, since you allow languages and
interfaces with CGI and Perl (and probably SSI) what allows the clients
to still create symlinks anyway. But, BESIDES that point, symlinks
were just one of MANY ways clients could exploit your setup.

There is no need for a user to be able to create a symlink on the
system
for a website; if they absolutely need one and can justify it, I'll
do
it for them. But no one has had a good reason why they need to do
it.
Sure, there are plenty of reasons. Not having duplicate files that
all
serve up the same data. Moving sites around without having to
duplicate the content or use rewrite or redirect rules, or a ton of
other reasons. But, I remind you, this isn't about symbolic links
and that was one example.

They don't need symlinks to do that.

Really, get off the symlinks subject for a while. That was one trivial
example.

And sites can easily be moved - to a different directory, different server or even a different domain
-
with no changes in the code, if it's written properly. NONE of my
code is EVER dependent on any of those.

We're not talking about your code. Also, while there are other methods
to accomplish the same goal, symbolic (and hard) links can be very
useful. Also, some of the other methods would result in a lot more
overhead.

<snip. you have a strange way of quoting in this thread>

Actually, I DON'T trust my users - any more than anyone else. But
at least with a contract I have legal recourse against them should
they do anything harmful.
That doesn't have anything to do with the problem when someone with
ill intent gains access to your client's account, or that you can't
know all of your clients that well if you are very successful.

You're the one who claimed I trusted my users. I never did.

Perhaps I misread what you said earlier then. Anyway, good that you
don't trust your users, so when you said you know your users and don't
have reason to worry about them doing these type of things, you can
wonder what happens if someone gains access to their account that does
these things.
And even if someone gains access to my client's account, the client is
still liable (unless he can prove negligence on my part - which he
can't).

So, instead of worrying about being better secured, you take peace in
the idea that you can sue the client if your lack of proper security
results in someone being able to gain access to that client's account
and then deface the other client's accounts on the same server. I'm
sure your clients will be thrilled that if something happens because
you were too arrogant on usenet to listen to what someone told you,
that when their sites are wiped from the WWW, that you can tell them
you'll sue the client who was the victim of the unauthorized access. I'm sure that'll go over well.

What is not immaterial is all of your previous claims and
accusations, going as far to say I said things I never said, meant
things I never meant, and so say I'm not a competent server admin
regarding security issues, all because you didn't agree with me
(all before we even
discussed what I was talking about). Your method is better than
the need for world write, I said that myself, and I didn't reply to
attack or embarrass you.

You are assuming everyone can do step 1. It can be restricted,
quite
easily. And it is, on my systems.
I believe I replied to that misconception above, already.

In fact, my replies only come from the need to defend myself from
untrue accusations (all based on the fact you didn't agree, and you
attacked
me for it). So, coming to this final conclusion by calling your
bluff,
is hardly immaterial, and your clients could do these things.
However, this is certainly and obviously not going to go anywhere
and it won't progress, so I have left the offer open to you if you
ever want me to show you (even for a price -- but not for $200, you
have to be realistic and reasonable, else it smacks of an excuse),
as well as the
offer for others using the same type of setup as you. Beyond that,
I
suppose we can drop the subject. I'm willing to, if you are (that
is, at this point, I'm just replying to the posts).
I don't agree because it's not true.
Yet you won't allow anyone to prove otherwise, which is pointless.
Don't accept or make a challenge and start running your mouth (or
keyboard) making claims and accusations, egging someone on, only to
back down when they call your bluff.

No, I'm not going to waste my time.

Right, make accusations, lie, twist what was said, lie some more, accept
a challenge, make a challenge and then wimp out and make 4 different
excuses about why you can't let someone actually prove they are right. Good plan. Usenet is a wonderfully suited place for you to be, Jerry.

And it takes about 45 minutes to
an hour to set the account up - just because I don't do it very
often.
Any good sys admin would create a script to do this for them if they
it
more than once and it takes that long. I don't believe you, but I
can't prove you are just making excuses, but you can understand why
I'd think it.

As I said - I don't do it often enough to make it worthwhile creating
a
script.

Yeah, right. It takes your 45 minutes to an HOUR, and you've done these
same or similar steps manually over once or twice, yet you never
considered writing a script. I'm not buying it. Even with your
alleged secure setup and restrictions, those would be global. There's
little to nothing that would need to be done on a per user basis when
setting up an account. The fact is, you were making excuses. It's
astounding how wound up you get about being proven wrong, to go to such
great lengths. This is truly sad.

There is a time to write scripts - and a time to NOT write scripts. Part of being successful is knowing the difference.

Yeah. Sure. Whatever.


And I have tests that I perform to ensure security before anyone is
allowed on the system - just to make sure *I* didn't miss anything.
Yeah, sure. Keep backpeddling.
Nope. Not here.

Yea. Sure. Whatever. As long as you keep believing in what you say to
save face on a friggin' news group (which would be utterly insane!)
then I guess you're happy.

Among other things, the test do try to do step 1 in your scenario
Something you didn't understand or try, or you did and saw it worked
and just don't want to admit it (and even claim you don't allow
symlinks, which is ridiculous -- a very poor way to tackle that
security
problem). This is why I said instead of relying on PHP settings and
such things to take and make up for the lack of a good security
basis,
that it is better to go with the better foundation. Otherwise, well,
you'd be in your shoes.

No, you won't admit that you might be wrong,

The way you outlined how you've set up your server, I'm not wrong. If
you are lying about the setup, then I sure might be. Why not allow me
to prove it or not then (and not pay $200 or hear other excuses to do
it)?

and there ARE other ways to secure a web server that you're not aware of.

Of course there are other ways. To claim I'm not aware of them because
I know your method is lacking, is pretty silly.


(yes, I'm familiar with it - just didn't want to get into an
argument on the phone), and fail if they can do it.
Yeah, sure you're familiar with it (or were already). Whatever,
Jerry. I know for a fact that because of the Apache web server
design, that any file that can be read by the web server without
changing users,
will be able to be read or written to globally. There's no way
around it, because that's the way Apache is designed (and it's not
just Apache either, by the way, but since this is what the OP's host
uses, as well
as both of us, it was relevant to the example). Really, get past the
symlink aspect, because that was one pretty trivial example.

Sure - somewhere around 15 years ago or more, as I said before.

You're a liar.

I've been involved in Unix administration for a LONG time - close to 20
years.

As have I, yet I feel like I'm talking to a beginner with an ego for
some reason, whom won't listen and would rather claim he's right and do
anything he can to not be proven wrong (which explains the persistent,
relentless and all too familiar attitude you convey on usenet to
people).


Again, there's no point in you repeating what will or will not work,
or you insisting your server is secure or not from this, since you
refuse to allow me to show you on your system (and as I suspected,
you would just claim it doesn't work (though it's ironic you claim so
based on the fact that ln is disabled from your clients using it),
just like I suspected and called you on the excuse that it would be
some unreasonably large amount of money for you to set me up -- I
called
that as likely to happen before I even called you.) Really, enough
already. You know I've proven my point, regardless of what you say
or believe and that is why you grasped for multiple reasons of why
you
actually couldn't let me prove it to you. So, whatever, Jerry.
Nothing's going to change, and I'm just having to repeat myself (if
you don't listen or want to argue about it the first dozen times,
there's
no reason why anything's going to change). So, let's just move on
from this topic and call it done.
And there's no point in trying to convince you that your way is NOT
the
only way to secure a server.

You're right, there's no point (since I already know there are other
ways). I simply said that by what you've said, your method lacks in
comparison and that you open security issues between user accounts. Deal with it.

Some people are not willing to admit they don't know something.

Now would be an excellent time for you to look in the mirror and repeat
that line. I, for one, am willing to admit I don't know everything. I
am also willing to admit when I'm wrong. And I'm always glad to learn
something, even if it's from a person I loath. That said, I really
wish you would practice what you preach, for once in your miserable
life.

Remember - I'm not the one who said YOUR servers are not secure.

I know, because they are. And in comparison, your claims that your
method is just as good, are false. It's not a big deal, really. I
offered to prove it, which you then backed out of for fear of being
exposed as being wrong on usenet (gasp!) God forbid! Anyway, I am
pretty sure that when you accuse me of being incompetent and not
knowing what I'm talking about regarding security (and you also claimed
I've done it many times before) and making such inaccurate claims about
how secure your system is, I'm compelled to say that problems exist
with your setup, based on what you yourself have said about how you've
configured it. Yeah, I know that pointing out a fact to you means
"usenet war" if you don't want to hear it, but it leads one to another
area of the subject, when you act like "I never said your server was
insecure, why are you picking on me" and it smacks of someone trying
desperately to avoid being exposed for something they aren't and like
to claim they are, in pretty commonly aggressive ways (that would be
you, Jerry).

But you keep repeating that my servers are not secure

I repeat; based on what you've said about your server setup, they are
not as secure as suPHP for PHP in Apache and lower permissins (which
protect on many levels from many services). Instead, you're resorted
to removing or disabling common features in some futile effort to call
it "secure". The fact you backed out of your offer to allow me to show
you on your server of how insecure it is (you offered that chance and
then made 4 greatly different excuses of why you wouldn't after I
called you and let you know I was genuine), shows you have a pretty
good idea that I would indeed show you and that I'm right about what I
said. That doesn't mean I said you have poorly secured server in
whole, though I'm starting to believe it is (now), but that as I
originally and simply said -- it's better than world write, but it's
not as good as suPHP with lower permissions on the files. All of this
was because you couldn't accept that simple and factual (and proven)
statement. It didn't have to be a big deal, but you also couldn't help
yourself and had to resort to accusing me of various untrue things
along the way, all to try and build your ego, because you simply can't
be wrong (you might explode, I suspect).

- despite not knowing
how I have my security set up.

Except that you outlined much of your setup and method used throughout
this thread. Try again.

Nice crystal ball you have there, Tim.

I agree. It's super helpful to my special powers of insight, what with
you describing much of the methods you use to try and secure your
server. My powers are so strong, I'm even able to time travel, look
back at a post you've made earlier and even tell you exactly what you
said. I'm amazing, but don't let that deter you from your trolling
session.

Tim, instead of attacking Jerry (which you are by the way) why don't you put your money where your mouth is. If you want to 'help the community' then why don't you just start discussing your security measures here instead of behind the scenes (phone calls). If you want us to benefit, then act like it.

--
Norman
Registered Linux user #461062
.