Re: write with cURL

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.

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.

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


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

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.

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.

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.

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.

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.

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.
--
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. ... This is assuming that the PHP script runs ... of potential security risks from other users on the same server. ... Apache as the global web server user and thus needs world write ...
    (alt.php)
  • Re: write with cURL
    ... execute permissions. ... This is assuming that the PHP script ... runs as the global web server user (and it surely does given ... Apache as the global web server user and thus needs world write ...
    (alt.php)
  • Re: Permissions
    ... >> I have a new server and I have my files up there. ... and what those permissions should be. ... Apache on the server. ... In the ShieldHost admin interface, ...
    (comp.lang.php)
  • Re: What is an application server?
    ... > servers, and sometimes database servers. ... > server unless you want to isolate business logic from web services. ... the PHP scripts get executed by ... Apache, ...
    (comp.sys.sun.admin)