sifusteven wrote:
Rackspace replied:
Steve J: We recommend not using FTP layer it doesn' t work as well and
Steve J: as far as apache owning the files in our environment the user would own files apache won't own them.
Hmmm.....
Joomla seems to disagree with Steve J:
from
http://docs.joomla.org/Should_PHP_run_as_a_CGI_script_or_as_an_Apache_module%3F
What is the difference between CGI and apache Module Mode?
An Apache module is compiled into the Apache binary, so the PHP interpreter runs in the Apache process, meaning that when Apache spawns a child, each process already contains a binary image of PHP. A CGI is executed as a single process for each request, and must make an exec() or fork() call to the PHP executable, meaning that each request will create a new process of the PHP interpreter. Apache is much more efficient in it's ability to handle requests, and managing resources, making the Apache module slightly faster than the CGI (as well as more stable under load).
CGI Mode on the other hand, is more secure because the server now manages and controls access to the binaries. PHP can now run as your own user rather than the generic Apache user. This means you can put your database passwords in a file readable only by you and your php scripts can still access it! The "Group" and "Other" permissions (refer Where can you learn more about file permissions?) can now be more restrictive. CGI mode is also claimed to be more flexible in many respects as you should now not see, with phpSuExec (refer Permissions under phpSuExec) issues with file ownership being taken over by the Apache user, therefore you should no longer have problems under FTP when trying to access or modify files that have been uploaded through a PHP interface, such as Joomla! upload options.
If your server is configured to run PHP as an Apache module, then you will have the choice of using either php.ini or Apache .htaccess files, however, if your server runs PHP in CGI mode then you will only have the choice of using php.ini files locally to change settings, as Apache is no longer in complete control of PHP.
and Nicholas K. Dionysopoulos of Akeeba Backup fame:
from
https://www.akeebabackup.com/documentation/akeeba-backup-documentation/web-server-ownership.html
In the context of web site management, Apache is of special interest. Apache is the de facto web server for Linux systems and is being used by over 50% of Internet sites, according to NetCraft's August 2008 survey. Chances are you are using it on your site, too. Apache, like most UNIX services (affectionately called daemons) uses the feature to drop privileges. The user and group under which it runs are defined in its configuration files. These configuration files are usually out of the reach of regular users (like you!) on commercial hosts, for security reasons.
There is a special case which acts as the exception to the Apache rule. Many commercial hosts run suPHP-enabled Apache installations. This is an extension to the normal PHP's mode of operation which allows each PHP page to run in a process owned by the file's owner (more on file ownership in the next sub-section). This means that each of the PHP files under your account on such a host run as the user which has been assigned to your account. And, if this still isn't apparent to you, such hosts nullify the burden of ownership and permissions (more on permissions in the next section). To put it clearly: with suPHP the file owner, your own user and the Apache user are one and the same. If you are looking for a decent host, find one which is using suPHP. It's better for security and removes a lot of administrative burden from you. A win-win situation.
and finally from Sam Moffatt of Google Groups Joomla Bug Squad::
https://groups.google.com/forum/#!topic/joomlabugsquad/SF6lUy_vbII
Apache 2 handler would mean the system is running under the Apache
users context which on a shared hosting environment is usually not the
end users context. This will cause ownership issues when Joomla!
(running within Apache's context) tries to write to files and folders
owned by another user that prevents the Apache user from writing those
files. So yes this would be an ownership issue as a root problem.
Unfortunately this configuration is rather common and is why there is
an FTP layer in place so that they can log in as themselves to manage
everything. It is also on shared hosting a possible security
vulnerability depending on what other safeguards they have in place.
As always the choice is yours as to the direction you want to proceed.