How do I change the default open_base_dir restriction

[AD7six]

Hi,

I write this message in part on behalf of my sys admin, who receives endless requests from me to 'fix' our Plesk servers each time one of our PHP sites suddenly shows a white page - caused by an open_base_dir restriction which was manually removed reapplying itself by some Plesk process.

We work with a number of servers at my present company, all of which are using Plesk Control Panel 8.6. I'm finding that the open_base_dir setup that Plesk uses by default to be a problem, and more importantly promoting insecure practices such as storing tmp files in a web accessible location (i.e. - making the classic upload a phishing.zip file to a vulnerable web and navigate to domain.com/temp/uploaded/files/can/be/found/here/phishing.html possible)

The setup I have always used, irrespective of the architecture in use is as follows: http://bin.cakephp.org/view/356756558

Subdomains are created using the same technique/setup.

We'd like to know how to remove entirely open_base_dir by default or at the very least change it to be the home dir of the domain user; and ensure that, for example, whenever someone creates a new domain via the Plesk admin panel - the open_base_dir restriction that we've removed/changed from the vhosts or other conf file does not get re-applied - which is what happens at the moment.

I hope later versions of Plesk don't use open base dir at all - it is to me only a needless addition to setting the right file permissions system wide in the first place (i.e. don't give the web user permission to execute/read anything it shouldn't be able to)

I've searched the forum http://forum.parallels.com/search.php?searchid=1863286 and googled around for resolving open_base_dir problems with Plesk but only found answers that aren't really acceptable. We don't want to edit each domain removing a default - which reapplies itself every time we create a new domain. We don't want servers that are insecure by default with some false logic that PHP files should never leave their own DocRoot, and can only be secured (in this regard, because of course there are many ways to exploit a web app) by manual/scripted post-processing.

Please let me know how I can continue to use Plesk without fighting against the open_base_dir restriction which seems to being forced upon us.

Regards,

AD

 

[ipwtech]

There is no way that I know of to change the defaults. There are ways to systematically tackle this problem through scripting. Since the Plesk API is very simple to use with BASH scripts you could write a script to check for new domains every X minuets/hours/days. When a new domain is found create its vhosts.conf to add your own custom open_basedir restrictions.

The default open_basedir settings gives you the ability to write to 2 locations for each website. There should be no reason to write to any other folder. PHP temporary sessions written to /tmp should be plenty safe.
- /tmp
- /var/www/vhosts/domain.com/httpdocs

If you find a way to change the defaults remember to post it here so others can learn how.

 

[AD7six]

Hi ipwtech,

Thanks for the reply.

I think you've misunderstood the problem. With openbase_dir as configured by default by plesk you can't read anything except /var/www/vhosts/domain.com/httpdocs .

Cheers,

AD

 

[IgorG]

Look at the following KB article http://kb.odin.com/article_41_432_en.html Maybe it will help.
The open_base_dir restriction is usually made for the security reasons. It's very very dangerous to disable it server-wide. If you do it your system is vulnerable and easily can be hacked. By disabling the restriction you're allowing every php script (for example) to execute every program on the server. If you are aware of what you're doing, you can try to input
the same value as in vhost.conf in /etc/php.ini file and restart apache.

 

[AD7six]

Hi Igor,

Thanks for the reply, I can understand from a sysadmin's point of view that restricting php scripts to their docroot and a tmp folder seems (and I stress seems, as from my perspective it's naive) like a secure policy. This issue was the first of 2 I wanted to dicuss, I'll summarize the second issue after responding as it's related and now relevant given your reply.

Your reply has helped in that you've confirmed it's:
- possible to, via php.ini, make all webs able to access a single common location, which doesn't help because there isn't really one
- not possible at all to prevent or modify plesks default open basedir usage.

To me that means that Plesk's answer is: should a user want to, by default, allow a web to put/read anything from a (web)protected directory then they need to add the path /var/www/vhosts to their php.ini file - do you agree with this conclusion?

This however also open the path /var/www/vhosts/anyotherweb.com to be accessible, and is restricted only by file permissions - which ordinarily isn't a problem.

Returning to plesks default open base dir policy for a moment, there is one minor and one massive problem with it - maybe you have a proposal.
- Library files which have no public facing functionality forced to be in a public location
- What is a php application supposed to do with files that are not temporary in nature and should not be (directly or at all) web accessible?

A simple example for the first point is the file with the db connection data, and whatever else in it. let's call it config.php - why does it have to be under /var/www/vhosts/example.com/httpdocs. another example is the folder ".svn" depending on the server config (and I don't know if this is already accounted for but it's just a common example) directly accessing a file in a .svn folder will either error out, show the files contents, or execute it - why give the possibility for example.com/somelibdir/.svn/entries to be accessible?

Regarding the second and most important point, most php sites include user interactions which include creating or uploading files that are not temporary. Typical examples would be uploading a theme for a cms, changing your avatar on a forum, or uploading media for any system which protects public access to uploaded content or an sqlite database. Especially the latter why is it forced to be in a web accessible dir.

It's a bit weird from my perspective to (need to) point this out but from a random reference (http://www.madirish.net/?article=204): "For instance, files should be uploaded to directories that exist outside of the application path." The reason to do so is to completely eliminate the possibility of a user successfully uploading something malicious which, if for whatever reason they know the server logic running means, they can then immediately access via the web. From my perspective as a php developer, the doc root is one of the paths that SHOULD NOT be web writeable by default yet with plesk you are pretty much forced to make it so.

So now a brief mention of the related problem.
Consider 2 domains (only) on a plesk server neither should know anything about the other. As apache runs as apache:apache - created files and folders are created with user apache and group apache. To be able via ssh/ftp delete or manage these files by a domain-owner ssh/ftp account - these files need to have permissions 777. Therefore by consequence of using plesk you are forced, by default, to either habitually access your servers using root access (it's an awesome touch that user passwords are stored in plain text in /etc/psa/.psa.shadow and therefore effectively elliminating the possibillity of adding any user to the sudoer group by the way), or, change the permissions of anything that apache needs to write to to be 777.

Adding all of this together therefore means that, by default:
- everything that php will use needs to be in a web accessible location, including temporary/cache/data files and folders that are not transient
- to get around files and folder created by apache being un writable/deletable by a normal ssh/ftp user they need to be 777
- therefore the whole, or bits of, the doc root is world writeable.

Alternatively, you are forced to either:
- 'restrict' all webs to the vhosts folder (if at all, because with such a broad restriction it's a bit pointless), and therefore grant path access for any website to any other website's files
- regularly use a script like this: http://code.assembla.com/mi/subversion/nodes/misc/scripts/unplesk

So, as you can obviously detect I am not a fan by any means of the way plesk's permission system wrt php sites is designed. I would not describe myself as a sys admin, however I do know how to write secure php apps - or much more importantly how to exploit an insecure/badly written one (of which I've written a few )

In conclusion: Is plesk going to listen, or do I continue to either make our servers insecure or run unplesk via ssh as root?

Regards,

AD

(Probably relevant: Personally, I don't like apache at all and much prefer lighttpd, I'm therefore hoping that someone can point out how to avoid the permission mess I'm describing)

 

[SarahK]

Disappointing that AD7six's post wasn't addressed as I'm faced with the same problem. Having decided to migrate a site with 23 subdomains all running off the same program files I'm now faced with the unenviable task of having 23 copies of the same file! Talk about maintenance issues!

I'm not sure what version of plesk the host is using but I know I don't have access to the conf files. I reckon I have 24 hours to get this working or back out the migration and return to my old hosting company.