Making Apache able to write to PHP files with PHP running as DSO?

You can write your config files under a temporary directory such as /tmp/config/. Then, you can execute a shell script to copy the config files from /tmp/config/ to the desired location.

To grant the needed permissions, you can add the user nobody to the sudoers file. The entry should look like:

nobody   ALL=NOPASSWD: /path/to/your_script.sh

The shell script (don't forget to add execute permission).

cp -r /tmp/config/* /desired/path/to/config

In PHP, you need a small code snippet like:

<?php
$output = shell_exec('sudo /path/to/your_script.sh');
echo "$output";
?>

In a shared environment everything gets a bit complicated when it comes to security concerns. By changing the file ownership to 'nobody' you give Apache write access to that file but, if the PHP module doesn't have settings to restrict each virtualhost to each its own directory, it would also give others access to it. Check how it's set up in your environment.

Apache usually runs as user 'nobody' and group 'nobody' so you could play with group permissions too. Change the file's group to 'nobody' and set permission to 664.

If you can't change the file's owner or group, FTP usually lets you change the permissions. Assuming that Apache isn't one of the user/group that owns that file, you'd have to set it to 777 which is very insecure but it all depends on the kind of environment you're in. Perhaps you can set it temporarily, install you app and change it back to 644 or 444 (read-only).

I would only do this on a development server in a secured environment. Many PHP applications will generate the file to the screen so that it can be copied safely to the configuration directory.

The quick (and insecure) way to do this is to execute chmod 777 . from the directory where the file should go. Before doing this run ls -ld . to get the permissions you will be setting them back to. In some cases the required directory will not exist, so you will need to create it first. Immediately after the configuration file has been written, reset the directory to its original permissions. The correct command is likely chmod 755 . or chmod 750 . run from the directory. Verify with the ls command.

Change the permissions on the configuration file so that Apache can no longer write to it (chmod o-w configfile). Applications often come with example configuration files. Placing one of these in the configuration directory and editing may be a better approach. This requires that you learn and understand the configuration options. You may be able to use the online configuration script to assist your edits.

This is the typical issue running PHP as a DSO with cPanel, but it apply also to other setup.

When running this method, PHP processes are handled by the user that is running httpd. In most cases, this user is the 'nobody' user. This means when PHP interacts with files on the file system, they have to be accessible by the 'nobody' user. This creates permissions issues as your normal cPanel based user will not have access to RW (read/write) files that are owned by the 'nobody' user without the correct permissions changes. Most PHP web apps/scripts need to write to files and directories and if they are owned by the cPanel user, without changing the permissions on the files/directories to 777, it will cause issues and in some cases, break your website(s).

So in this case you can just and only manage the permissions manually, setting them to 777

When running this PHP method you will have to manually manage the permissions on a per user basis to ensure that your PHP apps/scripts can read and write to the files and directories of which it needs to function.

Or, better, if you can move to Mod_SuPHP and you don't have performance issues (as DSO is much faster), you will be able to run PHP as the user running cPanel.

If we overlook the permissions issues that one can run into with running PHP through DSO, there are some some benefits to it, when compared to SuPHP. The first is speed. Mod_PHP is faster than Mod_SuPHP. This is mainly due to the fact that every request that is processed by Mod_SuPHP is wrapped to run as the user that owns the files. This might not be very noticeable on lower traffic sites, but on higher traffic sites, it can add up pretty quick. The second is full functionality with PHP optcode caching additions such as eAcclerator, APC and Xcache. To net the full benefit of a PHP optcode cache, you need a shared user which is used when caching the compiled PHP byte code and running PHP via a DSO runs PHP as the 'nobody' user fills this need. You can tell if your server is setup to run PHP through a DSO by going to the WHM and looking under Main >> Service Configuration >> Apache Configuration . >> PHP and SuExec Configuration

Here you can find more details:

https://helpdesk.wiredtree.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=1663