Re: write with cURL

Jerry Stuckle wrote:

Tim Greer wrote:
Jerry Stuckle wrote:

Tim Greer wrote:
Jerry Stuckle wrote:

Tim Greer wrote:
Jerry Stuckle wrote:

Tim Greer wrote:
Jerry Stuckle wrote:

Tim Greer wrote:
Ylva Poelman wrote:

The problem is that I do not want to change an existing
file, but to create a new one, write to it and saven it.
Then the directory you create the file is needs world read,
write and
execute permissions. This is assuming that the PHP script
runs as the global web server user (and it surely does given
the problem you have). So, create a directory and set it to
chmod 1777 (or 0777 if you can't add the sticky bit) and then
have files created there (or wherever you need, though it's a
terribly bad idea to set the primary web root directory
itself to world writable).
World read/write is VERY BAD. It opens the website to all
kinds of potential security risks from other users on the same
server.

Rather, it should be user and group read/write, and ensure the
web server itself is part of the group.

I made this suggestion because their web host appears to run
Apache as the global web server user and thus needs world write
permissions to
work. I doubt the OP has permission to configure the web
server in this case and it doesn't appear their hosting
provider has it set up
that way. Also, if you have the web server added to the same
group that the user belongs to (for read and write permission),
you still need to give that group write privileges all the
same, which imposes many of the same risks as setting privs for
world (now it just applies that same logic to group).

That is incorrect. It does not need global write permission. I
don't have it on ANY of the servers I manage.
I didn't say it needed global write permissions, I said the group
Apache
runs as still needs write permission. Hence, any PHP scripts on
the server have the same write permissions, since they all allow
Apache's
group write. Hence, any PHP script ran on another account, has
the same write permissions to one user's file as their own PHP
script does on their account (if it has write/modify/delete
permissions).

Incorrect, if the server is set up properly.
I guess you think it is, but you're mistaken.

You obviously don't understand how to set up a server properly. It
is secure.

In fact, I do, and unlike you whom just comes to usenet to run his
mouth
and argue with people, I DO know what I'm doing. Put up or shut up,
for once in your life. I'll offer you an account on my server and
you
offer me one on yours. Give me 1-2 minutes and I'll exploit the PHP
setup you have by accessing files owned by other users, regardless of
what restrictions you have in place to try and make up for not having
the right setup. If you can use PHP on my system to read another
user's file that the user has lower permissions on (yet PHP still
works, go figure!), and if I can't access another user's file on your
setup, then I'll give you $100 on top of it. I'm serious. Instead
of just arguing with people about how smart you think you are, put up
or
shut up. You have no idea what you're talking about and you want to
insist that you're right and I'm wrong. So, let's prove it.


I don't give trolls an account on my server.

There's the Jerry I've come to know and love. Right, I'm a "troll"
because I didn't remain silent when you made a claim about how you're
right and someone else is wrong, even though I went to great lengths to
explain the differences. You know I'm right, so you won't accept the
challenge.

Plus, in order to do it,
I'd have to set up an entire website for you, etc. I'm not about to
do it.

An entire web site? Just set up an account Jerry (being a user with a
web root, that's all that's needed). You don't have to take over a few
seconds to do it, but I guess you don't know that either, you server
expert, you.

Now if you were a paying client, I would do so.

Okay, I'll pay for your smallest plan. I won't charge you to set you up
on my server, because I am not trying to avoid the challenge. I'm
calling your bluff. And, I'm not out to do anything but to show you
(for your benefit), not to win some usenet argument with you (though I
do maybe have the possible benefit of you learning something and maybe
actually dropping the topic when you're physically proven wrong).

And no, you don't have the same exposure.
Correct, not the same as global write, just the same Apache group
write.

With world read/write,
anyone
can access the files through ftp, ssh, etc. That does not have
to be the case - and is very dangerous.
I wholly agree. The idea of using Apache's group as write only
allows Apache and the user write access then, rather than anyone
with any
service. It is indeed better, but I still think it's too much of
a risk to allow Apache's group write access, since all PHP
scripts ran by any user on the server will have the same write
access to that same
file on another account. Again, a far shot better than world,
but I doubt this user has the ability to change how their host
runs the
service now anyway. Thus, if the OP made a suggestion to their
host, they should ask them to install suPHP, which is a better
solution than global or Apache group (it can still use Apache
group to offer web root protection, and then lock it down with
PHP scripts and its files being 0400, 0600 or 0700 and not
needing to be higher, ever).

Granted, that would make is so the web server will have read
and write access that only root, the user themselves and the
web server group have that access to (and not just any user
would, so it is better than world), and thus it's slightly
better in that regard, but it will still allow any user's PHP
script to have the same write, modify and delete access to the
user's files, since it'll run as the Apache group, too.
Instead, I recommend having the host implement suPHP and not
run PHP in the Apache API, so only their user and the web
server have read, write
and execute permissions. But, that's still up to their web
host, and it doesn't sound like either of these suggestions are
viable options for them.

No, this can easily be handled with the PHP configuration
Yes, it is easy. That doesn't mean the user has control to
change it, or that their web host will change it if they request
(maybe they will
though?) Oh, you mean so every user can't write to another
user's file
they allow Apache's group to write to. I wouldn't say that's
easy, it's able to be gotten around to still write to files
across the file system.

No, the user can't change it - wouldn't be much security if they
could now, would there be.
And that was my point. For their web host they are on, they do not
have a choice and will need to set it to world write permissions
for their script to work.

You don't know that. For instance, right now they might not have
group permissions set up properly.

Doesn't matter. If PHP can read it or write to the file and if PHP
is running in the Apache API, another user can read or write to that
file.


Wrong.

Just saying it doesn't make it so, and I've offered to show you on your
own server and have you try on my own.

And it is quite easy to set up, and just as "easy to get around"
as OS privileges - IOW, you can't.
It's not "as easy to get around as OS privileges". That's a
ridiculous
statement to make. Regardless of the web service, you can't "get
around" permissions settings that deny other users that aren't
allowed
to read or write to a file. Your suggestion specifically allows
all user's PHP scripts to execute as the same user and need the
same group
to have read and write permissions on files (for all users). Your
only way around that being a global security issue is to put
restrictions on
PHP settings and how it's ran, which can be bypassed. If the
permissions are low enough with something like suPHP, then there's
an absolute method that will not be able to be bypassed unless you
are a privileged user (in which case it doesn't matter the method).

Just as it is impossible for a script to write to another user's
site if
the security is set up properly.

Then that means you're running suPHP and not running PHP in the
Apache
API. However, since you don't then one user's PHP script can read or
write to another user's file. Even with suPHP without the lower
permissions that's possible (I won't get into that), but with suPHP
and lower permissions, Apache and PHP can't overcome the permissions
locking it out from other users.


Nope.

Actually, "Yep".

And one user's PHP script can NOT read/write another user's
files.

Yes, they can, if the PHP in Apache API install is used and PHP needs
access either as world or as a shared group, then another user's PHP
script on the same server most certainly can. I've offered to prove it
to you on your server itself (even if I have to sign up for an
account).


You claim it can be gotten around -
yet you provide no examples of how this can be done.

I said I'd email you how, and you never took me up on the offer. Now
you insist I am wrong and you are right, and that I don't know what
I'm
talking about. Fine, so let's prove it. Let's give each other
access to the other's server and I'll prove it to you in a matter of
100
seconds. Then I'd like to see you bypass my setup.


You can email me - my (munged) address is in my sig.

I asked you several times over the last two days to email me and take
this off usenet and I'd explain it, and you instead wanted to claim I
was wrong and try and claim I don't know what I'm talking about.
Because of this, I'm no longer interested in emailing you this
information and only have you claim it didn't work (and how wonderfully
secure your setup is), when in fact you either didn't try it or you
flat out lie to protect your ego. So, I will show you on your server
if you accept my offer. At this point, I'm only interested in proving
it to you, so you can't deny it.

It is 100% secure,

No it's not. Just because you claim it is, doesn't make it so. So,
put up, or shut up, Jerry.


Shows how little you know about security, Tim. But you've shown how
little you know before.

And, as usual, you just run your mouth because you freak out every time
I prove you wrong. Instead of debating it or proving it, you just
claim that the person you're arguing with doesn't know something or
lacks some skill. That's pretty easy to do on usenet when you just
argue with people instead of proving it. It's ironic that you're
sitting there with an insecure system and your lack of knowledge about
how to bypass your sad attempts at a secure setup, somehow to you mean
you've proven that the other person is the one that doesn't know.

and cannot be gotten around,

Yes it can. The fact you're so confident it can't says a lot about
you. Just claiming your opinion on usenet as fact isn't anything new
for
you, but here's a chance to prove it. I'm making a genuine offer.


Sorry, I'm not going to spend the time for a troll.

But you surely spend all day with yourself.

if it is set up
properly.

If it's set up properly, then it's not going to be your setup.


Yes it is.

No, it isn't. Hey, we're really progressing on this argument.


I'd like to see yo ushow how it can be gotten around.

And I've offered to show you. Are you afraid of being proven wrong?
I'm not, if I'm wrong, I'm willing to learn a lesson. Are you? See,
I know my setup is secure, so I'm making the offer without
reservations. You know you're not qualified and hence you won't
respond to that
challenge. Email me and let's get this going. The worst thing that
can happen, is you learn a lesson.


As I said - you've got my email address. Now show me how to do it.

I asked you several times over the last two days to email me and take
this off usenet and I'd explain it, and you instead wanted to claim I
was wrong and try and claim I don't know what I'm talking about.
Because of this, I'm no longer interested in emailing you this
information and only have you claim it didn't work (and how wonderfully
secure your setup is), when in fact you either didn't try it or you
flat out lie to protect your ego. So, I will show you on your server
if you accept my offer.

. Even
though all sites have the same user, scripts in one site can be
restricted to access only the files on that site.
But trying to restrict them isn't going to always work. There
are
methods around that which aren't very difficult to overcome. It
is
better to use another method like suPHP. Again, the method
you're suggesting is probably a good middle solution, being
better than global writes.

Proper configuration and they can't be overcome.
Yes, they can. And it is by all means not as secure as a
configuration that takes advantage of lower permissions (which you
can't make up for or emulate, you can only attempt to put in
restrictions).

Please show how it can be bypassed.

Take me up on the challenge and I'll show you. I'll give you an
account on my server first.


No chance, troll.

Right, lest you be proven wrong. Here's a chance for you to finally put
up or shut up, and instead of your patented arguing trying to look
smarter than everyone else when you're clearly not, you cower at the
offer. Ironic, too, is that you call people trolls, when the only
person that trolls, is you. Accept the offer and stop being a liar and
a coward.

If the web host doesn't offer that or won't change (they likely
won't if they're not already doing it), I'd suggest to just run
PHP in CGI (if the host offers CGI with the SuEXEC CGI
wrapper), as that will provide them with the same advantages of
not having to use world (or group w/ a shared Apache group)
access to anything, though it would require a trivial amount of
knowledge with permissions and likely adding the
shebang line to the top of any PHP scripts they'd be executing.
It may come down to that or finding a web hosting provider with
a better idea of what they are doing.
CGI is not necessary. All it takes is correct configuration of
the system.
CGI is necessary to prevent the same level of access by the same
group needed to write to any users file that they need PHP to
write, modify or delete, assuming it uses SuEXEC (otherwise the
same problem exists
anyway). You can try and restrict PHP's configuration and even
use "pre" filters if you must, but that will not stop every
method to open and write to a file in another user's account,
list those files or do
damage. If you don't believe me, please email me and I'll
provide some examples for you, as I'd rather not post a "how to"
here.
Not at all.
So _you_ say.

That is 100% true.

Again, just saying it doesn't make it so. I wonder, is it in your
ability to apologize or admit you're wrong?


And YOU just saying it doesn't make it so.

Right, and I've offered to prove it. You are a coward, so afraid of
being exposed for being a troll and a liar, that you are desperately
trying to avoid living up to what you claim on usenet.

I challenge you to show how it can be bypassed.

I offered to email you, but you claim I have no idea what I'm talking
about. So, if you want to challenge me, let's give each other an
account on the other's system and I'll be happy to show you. What
are you afraid of, your system not being secure?


My (munged) email address is in the sig of every post. The fact you
are making excuses and didn't send me an email shows you can't do it.

Who's making excuses? Let's do this! I said we can give each other a
regular shared account on a server and prove to each other what we
claim. You said you won't do it. Are you saying you will accept the
offer? I'm ready! I repeat: I asked you several times over the last
two days to email me and take this off usenet and I'd explain it, and
you instead wanted to claim I was wrong and try and claim I don't know
what I'm talking about. Because of this, I'm no longer interested in
emailing you this information and only have you claim it didn't work
(and how wonderfully secure your setup is), when in fact you either
didn't try it or you flat out lie to protect your ego. So, I will show
you on your server if you accept my offer.



All that does is move the security from PHP to the OS, at
an additional cost of performance.
It does add a performance hit when the CGI process is spawned
outside of the existing httpd process itself (not embedding it),
but the difference is trivial and the advantages are significant in
many aspects (from per process and user control of resource usages,
concurrent processes, run time, etc.) to abuse tracking, per user
controls or acl's, to securing your files and scripts from other
users on the system.

If it is to be run as a different user, it must be spawned outside
of the existing httpd process.

Yep.

On a busy server, the difference is NOT
tivial and can add up quickly.

Only if your code sucks. CGI overhead isn't detrimental. And, any
site that gets SO much traffic that they have it negatively impact
the server, shouldn't be on a shared host, since in the Apache API it
will
still be too busy of a site to be on a shared server. On a dedicated
server, I'd suggest people do run PHP in the Apache API, because
there are no other users on the server and they have the script run
as a non
privileged user. Even so, the difference of the overhead (which is
low), is overcome by having the benefit of being able to control that
user's processes. Just as a user's PHP script on a shared server in
the Apache API can get out of control without a good way to prevent
it from overloading the server, you can do this per user and per
vhost with CGI.


Not at all.

What? You disputing what I said? IMPOSSIBLE!

Of course, you must not have administered any busy
servers, or you would understand the overhead.

You must not understand what I said about controlling processes and
resources. You must not have understood that I said on a shared
server, if a site is so busy with quality code, that CGI alone presents
a massive problem, that they are a site not suited for a shared server.
Oh,. and all of the added benefits I also had outlined, but please
dismiss all of those things I've said (even when I said that CGI
overhead is real and is slower, but it's not by much).

FASTCGI helps, but still does not
eliminate the problem.

It doesn't help a lot, I agree, and doesn't solve the issue in Apache
with PHP in the Apache API.

And it is unnecessary in a properly set-up server.

You _think_ you have a properly set up server, and in some sense you
might, but it's not as secure as it could be.


It's as secure as anything you've ever created.

Wow, you're so dynamic and exciting. Now, please feel free to accept my
offer and prove what you say. Your arrogance is only actually
impressive to you, not the viewers of this group.

The same level of security can be
had when running PHP as a module.
No, it can't. That's the difference between a global user (or
group) running your script, or your own user.

You obviously do not understand how to set up PHP properly.

You're wrong, and you keep saying that (I get it). So then, accept
my challenge and let's give each other an account on the other's
system
and prove it. It's that simple.


Become a paying client and I'll set it up for you.

Okay, I'll email you as soon as I reply to this.

It's how I have my servers set up,
And you're not a server admin, you don't specialize in this area,
and it
shows by your stubborn claims. I know you like to argue with
people on AWWW as well as here, but enough already.

Actually, I've been administering UNIX servers for almost two
decades.

Yet, you still don't know what you're doing.


A lot more than you do, obviously.

Yeah, yeah... you're smarter than everyone and anyone that doesn't agree
with you or your claims is a troll that has no clue what they are doing
(let's ignore the fact that they can prove it, because this is usenet).

The difference is, I know what I'm doing and how to set something up
properly.

You say so, so put up or shut up, Jerry. It's that simple.


You said you'd email me a way to do it. But you never have.
So put
up
or shut up, Tim. It's that simple.

I repeat: I asked you several times over the last two days to email me
and take this off usenet and I'd explain it, and you instead wanted to
claim I was wrong and try and claim I don't know what I'm talking
about. Because of this, I'm no longer interested in emailing you this
information and only have you claim it didn't work (and how wonderfully
secure your setup is), when in fact you either didn't try it or you
flat out lie to protect your ego. So, I will show you on your server
if you accept my offer. I'll contact you to pay for an account after I
post this.



and scripts from one site cannot access the directories on another
site - even though Apache is a member of both groups.
It can be exploited.

Please show how.

Give me an account on your system and I'll show you. I'm not going
to give an example here and have you just immediately reply claiming
it
doesn't work on your server when I know it does. What are you afraid
of?


Become a paying client and I'll give you an account on my system.

Then I will. Let's see what happens when I call your bluff, you lying
coward.

Of course, you need to set everything up properly - but that's
true in any case.
You can continue claiming that, but you're spreading
misinformation, and
it's all for nothing. The OP doesn't have the ability to do either
set up themselves and they therefore HAVE to use world write to be
able to modify or write to that file in their case, and that's a
fact, and why
I said they would have to. I never claimed it was a good thing to
do,
but something they'd have to do in their situation. Regardless of
what
you continue to claim, you're wrong. PHP in the Apache API,
regardless of what settings you have or try, is always less secure
from a user
perspective than CGI (using suPHP). Don't believe me? Let's give
each other an account on each other's server and see how many
seconds or minutes it takes for me to show you a way to exploit
your set up, and
let's see you spend days or weeks and get nowhere on mine. That's
a public and open challenge, because I'm really tired of your
arrogance on the newsgroups where you ramble on about how your
opinions are somehow fact and you make such an effort to argue with
people when you
actually have no idea what you're talking about. I've tried
repeatedly to explain and offered to take this to email where I
could show you, but you'd rather tell me I'm wrong.
I'm not saying anything about the OPs ability.

No, you're not, you just wanted to try and argue with me about my
suggestion to them, and there was no reason for it. And, as usual
with you, you had to escalate it into an insulting response claiming
that you are a know-it-all and to claim I don't know what I'm talking
about.
I do, and you're wrong. So, since you don't believe me, let's give
each other access to the other's system as a normal shared server
user and I'll show you.


And I'm just telling you your suggestion is WRONG, WRONG, WRONG,

Yet, you're wrong, because I NEVER disagreed that world write is a bad
idea. What are you missing?

and
exposes them to all kinds of potential security problems.

No kidding, I never disagreed. I simply said that if their host has it
set up where they can't write to a file unless it's world write, that
that is what they'll have to do in their situation. I never disagreed
that it was a bad setup.

The fact you even suggested it means you don't understand security!

How dumb can you be? Seriously? I didn't set up the server they are
on, they aren't my client, they are on another web hosting provider.
That web hosting provider requires world write permissions to write to
a file. I said they'll either have to set it to world write to do what
they want (write to a file), or run PHP as CGI w/ the SuEXEC wrapper
and probably add the shebang line to have it run as their own user to
avoid world write. I didn't suggest they should setup the server this
way, I suggested that was a solution they could consider if they wanted
to write to the file. You're so wound up in your trolling and arguing,
that you seem to have missed all of that, but it's sad that you have
resorted to trying to use that thing you're so confused about as some
claim that it's proven I don't understand security. If someone doesn't
lock their car and asks "How to I get into my car?" I'll suggest they
use the handle, since it's not locked (a bad idea), but I didn't
suggest they not lock their car. Are you getting it, now?


I'm calling you on
your
statements

No, you're not. You're desperate to prove you know more than anyone
else and to argue with anything they say, regardless that you are
absolutely wrong. If you don't know there are ways to exploit your
setup where users can access each other's files over PHP, fine, but
that doesn't make me wrong because _you_ don't know. I offered to
email me and I'd tell you, but you didn't and come out acting like
you
are right and need to tell me I don't know what I'm doing. So then,
Jerry, simply put up, or shut up. I'll prove it to you in a matter
of minutes if you accept my challenge.


Nope. I'm calling you. Now put up or shut up.

No, you are trying to claim that setting up an account is such a long
process that you have to charge me. So, fine, I'll pay. That's right,
I'm calling your bluff.

that setting world read/write authority is necessary.

My statement said that in their case, it is. There's nothing to
argue about that, but far be it from you not to argue.


Yep, you don't understand how their system security is set up, which
is
why you have to say that. Giving world read/write access is itself
the mark of an incompetent administrator.

So, YOU do understand how someone has their server set up, even though
you don't know who they are or anything about them either? Looks to me
like their host is requiring world write permissions to be able to
write to the file. I mean, seriously, are you a complete idiot here,
or what? If they need to give world write to be able to write to a
file, that's the solution to their problem. I said myself it's
dangerous, so what are you yammering on about to say this is proof that
I'm incompetent? Do you realize how that makes you sound?

That
is VERY DANGEROUS and should not be recommended to anyone,
especially in a public newsgroup.

This is pathetic. It was suggested in this news group to this user,
because that is the ONLY choice they have to write to a file on their
web server, unless their web hosting provider changes the way they
run
PHP. It's ridiculous to claim that it shouldn't be recommended, when
it's their only option (that or running PHP as CGI with the shebang
and
proper permissions, assuming the host offers CGI with SuEXEC). I
even said it's not a good thing to have to do, and to be careful what
they set to world read and write, but you felt the usual overwhelming
urge to argue with what I said.


I stand by my statement.

That's because you're dumb, look above about your reasoning for what
you're saying about me. It's utter nonsense.

By even suggesting it, you are showing how
incompetent you are.

Again, I didn't suggest that it was a good idea, I suggested this is
probably the only way they can have PHP write to the file. It's sad
that you don't understand the difference. You are just grasping for
straws here, especially to continue to insist that this shows I'm
lacking in skills because of what that guy's host does.

Now if they get hacked because they followed
your "advice", are you going to pay for the damages and restore their
system?

The OP asked why it wouldn't write to the file, and I told them why. I
said it's a bad setup, a bad idea and isn't secure. I then suggested
they could consider using a CGI version with the shebang line if the
host used SuEXEC, which would then solve the security problem. Of
course, I've explained this several times and it's obvious from the
start, yet you continue to try and use this to say I'm wrong?

Only those who don't understand the implications (or how to set up a
server) would make such a recommendation.

This is the sort of nonsense I've grown used to seeing from you. A
user is on a web host that PHP runs as the global web server user,
that is what they have to do to write to a file (give it world write
permissions, or world read/write for a directory to create a file
within it from PHP) and because I explain to them that true and
accurate information, you reply as if I fail to understand the
implications, even though I specifically said myself that it's not a
good, secure way to have a server set up. So, even though I never
disagreed with you, you continue to argue and use that as a basis to
show that I somehow don't know what I'm talking about and the simple
fact I made the recommendation is proof (even though that's how their
web host has the server set up -- something I have no control over
what
the OPs web host does). Yet, none of that sinks in or gets through
to you.


Nope. A good Unix administrator will NEVER give such dangerous
advice.

You're a complete idiot. I repeat: The OP asked why it wouldn't write
to the file, and I told them why. I said it's a bad setup, a bad idea
and isn't secure. I then suggested they could consider using a CGI
version with the shebang line if the host used SuEXEC, which would then
solve the security problem. Of course, I've explained this several
times and it's obvious from the start, yet you continue to try and use
this to say I'm wrong?

So, fine, if you don't get it, I can't help you. However, I have
repeatedly offered a challenge to you. We each give the other a
normal shared account on our servers, and we see if the other canI
asked you several times over the last two days to email me and take
this off usenet and I'd explain it, and you instead wanted to claim I
was wrong and try and claim I don't know what I'm talking about.
Because of this, I'm no longer interested in emailing you this
information and only have you claim it didn't work (and how wonderfully
secure your setup is), when in fact you either didn't try it or you
flat out lie to protect your ego. So, I will show you on your server
if you accept my offer.

show how their setup can be exploited to read or write to other
user's files
that we want to prevent. I CAN do this, you CAN NOT do this. I CAN
prove it and thus the offer, and I'll even give you an account on my
server first, if you accept that offer. I say once again, rather
than just claiming you're right and someone else is wrong, here's a
chance
to prove it. I know that's a new thing for you to have to face
(actually proving what you run your mouth on about that you are
actually wrong about), so instead of words, put those claims into
action and take me up on my offer. It's simple, Jerry, put up, or
shut
up. Either way, I'm happy, because I'm honestly had enough of you
making untrue claims on usenet and pretending you know things you
don't (not that I'd normally care, except that you challenge what
people say that do actually know what they are talking about, and
that's
annoying). There's the offer, either take or it refuse it (though
the fact you'd refuse it says you know your system isn't secure, else
you'd
accept the offer). Instead of using your poorly chosen and lies of
words, let's make it real. The offer is there, unless you're afraid
of being proven wrong (because your words can't get you out of it --
and
apparently you are that worried about being proven wrong). Shameful.

No, YOU don't get it,

Ironic, the guy that doesn't get it insists that the other person is the
one that doesn't get it. Oh, usenet is fun.

and I can't help you.

The last thing you can offer anyone, is genuine help, and it's also
ironic that you insist that you'd be the one to help me. It's quite
the opposite. Boy you really get bent out of shape if anyone politely
suggests that there is a better way or you might be wrong and even
offered to have you email them to prove it. I wasn't going to shoot
you a random email, so I offered for you to contact me. Instead, you
went on a trollish rampage because you can't stand being wrong.

You have tunnel vision,
and think your way is the only way it will work.

Yeah, from the guy that keeps insisting that me explaining to the OP of
why they couldn't write to the file is proof that I'm not a qualified
server admin, is telling me that I can't see the bigger picture. Man,
you're a troll machine! You go, girl!

The difference is, I agree your way is safe, but has it's own problems
(i.e. performance). And my way works just as well, but without those
problems.

I know my method is safe (and safer) and I never said you disagreed with
that. What your problem is, is that you insist that your method is
just as secure, when it's not. I politely offered a follow up, and you
escalated it into an argument, like you always do (it's like some sick
addiction for you), and far be it from me for some clueless, arrogant,
known usenet troll to tell me something that's wrong without me
following up (which just eggs you on more, because you have some
emotional problem). It's absolutely unbelievable that you resort to
insisting that telling the OP the answer to their problem and even
discouraging them from using that solution, that you want to claim it's
proof that I'm a poor server admin that has no idea about security.
Talk about twisting things around, that's crazy, and there's no reason
for it. Instead of just saying "sure, I'll email you and give it a
try, because I don't believe it is a problem", you went on the trolling
rampage you are infamous for. So, here we are.

As I said, once more, finally: I asked you several times over the last
two days to email me and take this off usenet and I'd explain it, and
you instead wanted to claim I was wrong and try and claim I don't know
what I'm talking about. Because of this, I'm no longer interested in
emailing you this information and only have you claim it didn't work
(and how wonderfully secure your setup is), when in fact you either
didn't try it or you flat out lie to protect your ego. So, I will show
you on your server if you accept my offer. You have stated several
times that "if I pay" you'll set me up. So then, I'll contact you as
soon as I submit this reply and I'll pay for an account on your server.
There was no need for all of this drama and BS just to have you listen
to what I said, so I can show you (instead of arguing -- which is all
you wanted to do). No more nonsense, let's do this then.
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!
.

Relevant Pages

  • Re: write with cURL
    ... execute permissions. ... of potential security risks from other users on the same server. ... I made this suggestion because their web host appears to run Apache ... risk to allow Apache's group write access, since all PHP scripts ran ...
    (alt.php)
  • Re: write with cURL
    ... execute permissions. ... of potential security risks from other users on the same server. ... I made this suggestion because their web host appears to run Apache ... risk to allow Apache's group write access, since all PHP scripts ran ...
    (alt.php)
  • Re: Apache vs IIS
    ... Windows Server not on my Linux Server so there for I would chose IIS. ... Not that Apache is bad but ASP.NET is far easier and faster to create good web forms in. ... PHP on a IIS server is rather easy to run once you install PHP on a PC but if you only use PHP why not use Apache for Windows. ...
    (alt.php)
  • Re: write with cURL
    ... offers PHP, if they don't allow PHP to open and write ... Check the permissions on the directory the file is ... such as chmod 0666 test.txt ... their server configuration is, too, though. ...
    (alt.php)
  • Re: Apache vs IIS
    ... my Windows Server not on my Linux Server so there for I would ... IIS is designed for ASP, ... can run asp on Apache, ... in running php from IIS vs Apache. ...
    (alt.php)