Securing a directory

[incrediBILL]

Have a situation where I can't get my control panel (and I have full control of the server) to allow my PHP to loosen it's grip on the open_basedir no matter what I do, and I've followed all the control panel vendors instructions, no dice, they're baffled as well.

Yes, safe mode is disabled and with the other changes made, it still defaults open_basedir to:
/var/www/vhosts/example.com/httpdocs:/tmp

Ideally, what I wanted was a structure like this:

/var/www/vhosts/example.com/httpdocs
/var/www/vhosts/example.com/privatedata

Where the PHP code could run in httpdocs and read/write to privatedata which is outside the scope of the web server but still within the confines of a jailed FTP account, etc.

The only solution I've found so far, which appears to be about as secure as it gets without working around the open_basedir issue, is use a public directory and deny access from all via .htaccess

Ended up with a structure like this:

/var/www/vhosts/example.com/httpdocs
/var/www/vhosts/example.com/httpdocs/privatedata

And placed the following .htaccess file in /httpdocs/privatedata:

deny from all

PHP can still read and write /httpdocs/privatedata just fine but the web server can't touch it whatsoever from the outside world via the .htaccess deny all.

Seems a bit of a kluge, has anyone else ever run into this situation and found a more elegant solution or is this as good as it gets in a control panel environment?

[coopster]

Create your private directory in your site root as you desire. So ...

/var/www/vhosts/example.com/httpdocs 
/var/www/vhosts/example.com/privatedata

Now chmod/chown the new privatedata directory to match your httpdocs directory. Next, update your php open_basedir directive for this VirtualHost container by appending your new directory. Using your example:

php_admin_value open_basedir "/var/www/vhosts/example.com/httpdocs/:/tmp/:/var/www/vhosts/example.com/privatedata/"

has anyone else ever run into this situation and found a more elegant solution or is this as good as it gets in a control panel environment?

Yes, I have come across this before working with clients running on plesk. The plesk configuration makes things real fun sometimes because in order for this to work with plesk you need to add this to a vhost.conf/vhost_ssl.conf. So, I copied this very same directive from the plesk-created /var/www/vhosts/example.com/conf/httpd.include to use in the /var/www/vhosts/example.com/conf/vhost.conf file. I merely appended the directories I needed to be parsed by php to their original directive.

I first went through this when trying to apply php to the client error documents, by the way. By default the error docs were flat html, no php parsing going on. Grr.

[incrediBILL]

Wow, thanks a bunch!

I had done almost all of that except the instructions I got for doing the php_admin_value override in the vhost.conf file didn't work at all.

Your version worked first time, after rebooting httpd of course ;)

Now the base directory code can access all the subdomain accounts, which if I couldn't do this was going to make the site a complete mess.

This may solve my next problem because creating a directory in a public apache area from PHP set the owner as apache:apache so you couldn't actually use it until a cron job I wrote comes along every few seconds and resets the ownership to the local user. The stupid script has to idle until the cron job changes the owner and rights, then reading and writing can commence.

WHOOPS! Just tested the code and mkdir is failing to create new entries in privatedata with chmod 755. It could only read using the standard directory rights (755), had to chmod privatedata to 777 and then it worked. However, PHP is still creating all the files with the owner being apache:apache, but in this configuration I don't need a cron job to fix it with privatedata chmod'd to 777, which may have worked in the old configuration and I'm sure I tried that, who knows, but it's WORKING!

Just not optimal ;)

Of course when does anything ever work the way you really want it to work?

Thanks again, this is great!

[coopster]

User supplied content (via form submission) is going to be written to your directories under the permissions of the server user/group which is typically apache:apache and if you are using FTP to connect and drop files in the same directory you are going to get a mixed bag of owner/group permissions. You need to be careful because your FTP account will likely drop the file into the directory with a more restrictive set of permissions (as well as the different ownership permissions).

None-user-supplied content such as shared application processes can be handled differently. I include base application code from a directory completely outside of any subdomains/virtualhosts owned by root:root with global read-only rights. Shared application processes such as changing passwords, etc. You know, common code used across a bunch of subdomains. However, I allow my subdomains to access this directory via the open_basedir directive in each subdomains extended conf file.

Back to the user-supplied content ... where things get a little trickier is when you need to allow a subdomain the ability to write to its own specific directory. That's when I place it into a subdirectory within that domain's container, in plesk it is typically something like what you are doing with your privatedata subdirectory. chmod 0777 and chown to apache:apache and you should be fine. Just be very careful about what type of content you are allowing your user to upload and be sure you aren't parsing that content as PHP (or any other CGI-handler) from that directory!

[incrediBILL]

Don't worry, other than the quirks of PHP I'm familiar with all that except the old CGI code I rolled myself did a SU, opposed to this PHP stuff, always got the proper user/group from the account and set the rights to all the files accordingly.

Never had this apache:apache issue, no chmod 777s, none of that nonsense.

Not used to dealing with slop ;)

Now I see why everyone just shoves everything in a MySQL database to avoid all the rights and ownership issues of using actual files in PHP, sheesh!

[coopster]

LOL! Security and permissions are the same with Perl or any other CGI language. PHP just added more directives to the configuration which quite honestly I wish were not there sometimes. But I believe all this PHP config stuff started to help secure apps in shared hosting environments.