Re: write with cURL

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.

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 it is quite easy to set up, and just as "easy to get around" as OS privileges - IOW, you can't.

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


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. All that does is move the security from PHP to the OS, at an additional cost of performance. The same level of security can be had when running PHP as a module. It's how I have my servers set up, and scripts from one site cannot access the directories on another site - even though Apache is a member of both groups.

Of course, you need to set everything up properly - but that's true in any case.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@xxxxxxxxxxxxx
==================
.

Relevant Pages

  • Re: write with cURL
    ... potential security risks from other users on the same server. ... as the global web server user and thus needs world write permissions ... Hence, any PHP script ran on another account, has the ... Correct, not the same as global write, just the same Apache group write. ...
    (alt.php)
  • Re: write with cURL
    ... This is assuming that the PHP script runs as ... the global web server user (and it surely does given the problem you ... the global web server user and thus needs world write permissions to ... and execute permissions. ...
    (alt.php)
  • Other way to avoid fopen() for writing access error?
    ... I am dumping some data to a text file on my web server using a PHP script ... If I don't set the permissions for the file ... Is there another way to make the file writable by my PHP script? ...
    (alt.php)
  • Re: File permissions for a wiki-like site
    ... The question is what file permissions I need to allow for the ... content to be writable by my PHP script. ... The only one doing the writing will be the Apache user itself. ... I'd suggest you get a book on Linux Administration. ...
    (comp.lang.php)
  • Re: File permissions for a wiki-like site
    ... The question is what file permissions I need to allow for the ... content to be writable by my PHP script. ... The only one doing the writing will be the Apache user itself. ... I'd suggest you get a book on Linux Administration. ...
    (comp.lang.php)