File ownership and using PHP file commands

I have heard that on some older servers, when you create a file, it will assign 'nobody' or 'Apache' as the owner and this can create an opportunity for exploits.

I have also heard that more modern hosts will assign proper ownership, or at least ownership of the host.

Am I understanding this properly? How prevalent are older servers that do not assign the host user to file ownership?

Can file ownership be changes programmatically? Any thoughts or insights are appreciated...

You would get a better response from Apache experts by posting in Apache HTTP Server.

thx, reposted here:

http://www.phpfreaks.com/forums/index.php?topic=349457.0

There must be some solution here... How could all php file commands be subject to hijacking in a shared hosting environment.

The only real concern is that the "nobody" group/user may be used by something else. I don't see how changing it to apache.apache would be harmful.

Generally in shared hosting, the files you have control over are owned by you, so that users can only effect their immediate space and can't harm anything else on the server. Any respectable host will have this all setup properly.

File ownership can only be changed with by a superuser (which HOPEFULLY isn't what Apache is running as).

I have heard that on some older servers, when you create a file, it will assign 'nobody' or 'Apache' as the owner and this can create an opportunity for exploits.

I have also heard that more modern hosts will assign proper ownership, or at least ownership of the host.

Am I understanding this properly? How prevalent are older servers that do not assign the host user to file ownership?

Can file ownership be changes programmatically? Any thoughts or insights are appreciated...

This has nothing to do with age, it has to do with fundamental approaches to setting up apache with php.  This is not specific to php, the same goes for any serverside language, although some serverside languages do not have apache modules.  I will explain this momentarily.

To understand this a bit of history is in order.  Originally there was no provision made for webservers to run programs, but the NCSA which had created one of the first webservers (in a group that later would form Netscape), first confronted this need, they cooked up a spec for how webservers could be made to call programs.  This spec was named the "common gateway interface" or CGI, and lives on to this day in php's $_SERVER superglob, not to mention the ability of programs to be run in CGI mode.  CGI programs would get access to certain variables from the webserver, would get GET and POST variables through standard input, and anything they wrote to standard out would be caught by the executing webserver and returned as output (assumed in most cases to be HTML).

As CGI caught on and people started writing CGI scripts one of the issues that came up was that it is expensive to run a program as a CGI.  It has to be started up, memory allocated, executed, then memory deallocated, and the program shutdown. 

So the various webserver developers quickly realized that it would be helpful if they provided api's to their webservers that would allow people to write modules that could integrate with the webserver.  For apache these extensions are called modules, and in fact a lot of what apache does is based on a series of core modules that come with the server.

The PHP developers were quick to write a php module (mod_php)  and this is what you are talking about when you mention files being owned by nobody or apache.  When you are running a server with mod_php and your php script writes a file, that script is actually executing as the apache webserver itself, and it has the same privileges as the apache webserver, which is typically run as user nobody or apache for security reasons. So if you script needs to create an image for example, then the directory needs to be writeable by apache and the files will be owned by apache.

If you know what you're doing from a security and administration standpoint, this is actually a great way to go, because it's very efficient for php to run in apache as an apache module. 

The place where this is a problem is in SHARED HOSTING.  If you are on a shared host, and they have setup apache to run as mod_php, then anyone can write a php script and have it go read anything that apache is allowed to read, and write anywhere apache is allowed to write.

Shared hosts of any competence, do not setup apache this way.  They instead setup apache to run php scripts in cgi mode, utilizing a wrapper called suExec to change the permissions of the running program to be that of a particular user.  On a shared host, this is going to be the user that gets created on the server related to your hosted account.

Some of the lost performance can be regained via implementation of fastcgi, which implements some techniques that offset the cost of traditional cgi.

To be clear, there is no problem running php with apache and mod_php as nobody or apache.  On a dedicated or virtualized server that is what you would want to do.  Shared hosts are not going to do that, so the problem should not exist in a shared hosting environment.  These days, with so many virtualization vendors out there, I find it hard to recommend to people that they opt for shared hosting, when typically for a reasonable amount of money they can run a virtual server where they don't have to worry about running on a shared host.