BPS 2.5 caused admin dashboard to stop workring

Use FTP or your web host control panel file manager and rename the /bulletproof-security/ plugin folder. Let me know what happens.

Other things to try would be to use FTP or your web host control panel file manager and delete your Root and wp-admin htaccess files (download a copy of them first).

• This reply was modified 7 years, 2 months ago by AITpro.

I moved the plugin folder to plugins.disabled. That fixed the problem, but obviously BPS is no longer functioning. I then tried installing BPS from a new download, but the same thing happened. So I disabled it again.

The BPS htaccess files are still in place, so the problem must be in other BPS functionality.

One other issue: I’m getting these emails from BPS every five minutes, even though it’s disabled: ‘BPS Alert: The /bulletproof-security/ plugin folder has been renamed or deleted’.

We have 3 reports of this problem being caused by open_basedir being configured incorrectly. open_basedir is a directive setting in your server or custom php.ini file. This is an example of the problem using example code.

PHP Error message:

[Tue Sep 19 10:53:58.081085 2017] [:error] [pid 474] [client 178.162.197.211:45144] PHP Fatal error:  Uncaught exception 
'RuntimeException' with message 'SplFileInfo::isDir(): open_basedir restriction in effect. 
File(/home/admin/web/example.com/public_html/..) is not within the allowed path(s): 
(/home/admin/web/example.com/public_html:/home/admin/tmp)' in 
/home/admin/web/example.com/public_html/wp-content/plugins/bulletproof-security/includes/general-functions.php:891\nStack 
trace:\n#0

php.ini file directive setting:
open_basedir = /home/admin/web/example.com/public_html:/home/admin/tmp

Correction|Fix for that invalid open_basedir path setting:
Recommended: Comment out the open_basedir directive to disable it by adding a semi-colon in front of the code.
;open_basedir = /home/admin/web/example.com/public_html:/home/admin/tmp

Or add all the valid paths that are required:
/home/admin/web/example.com:/home/admin/web/example.com/public_html:/home/admin/tmp

Or

/home/admin/web:/home/admin/web/example.com:/home/admin/web/example.com/public_html:/home/admin/tmp

• This reply was modified 7 years, 2 months ago by AITpro.
• This reply was modified 7 years, 2 months ago by AITpro.

To confirm that this is the problem that is occuring on your website check your server’s PHP error log file.

• This reply was modified 7 years, 2 months ago by AITpro.

Well, that certainly explains what I’m seeing.

Unfortunately, I don’t want to stop using open_basedir, and I don’t want to add the site’s parent directory to the open_basedir directive. Why does BPS need access to that directory?

Looking at the errors I’m seeing in the Apache error log (below), it seems clear that unless I disable open_basedir completely, to fix this, I’d have to add ‘/var/www’ to the open_basedir directive. Not something I want to do.

Apache error log example:

PHP Fatal error:  Uncaught exception 'RuntimeException' with message 
'SplFileInfo::isDir(): open_basedir restriction in effect. 
File(/var/www/mysite/..) is not within the allowed path(s): (/var/www/boot13)' 
in /var/www/mysite/wp-content/plugins/bulletproof-security/includes/general-functions.php:891
referer: https://mysite.com/

• This reply was modified 7 years, 2 months ago by jrivett.

If you are using open_basedir in a virtual hosting environment to separate/isolate different sites on a vhost or VPS server then open_basedir is a pratical usage of that directive. If you think or believe open_basedir offers any security protection then that is false, a myth, bad information found somewhere in a dark alley on the Internet.

Why do you believe adding the /var/www path to open_basedir would make any difference at all? Do you think it would make your server/site less secure or something? If so, that is false.

One of the things we will be looking at in BPS code is the usage of this Global: $_SERVER['DOCUMENT_ROOT']; What we think is occurring is that some servers interpret this Global differently. ie Document Root is seen as a directory above the actual site’s Document Root folder/directory on some servers. Why that would be we really don’t have an idea about that yet.

• This reply was modified 7 years, 2 months ago by AITpro.
• This reply was modified 7 years, 2 months ago by AITpro.
• This reply was modified 7 years, 2 months ago by AITpro.

Your /var/www directory is a protected server directory. So access to the directory via HTTP/frontfacing should be impossible by default. The backend Architecture/Structure is wide open since any hacker worth anything who has gained backend access can manipulate/access/control dirs all the way to Root. In other words, open_basedir would not stop a hacker from owning a server.

• This reply was modified 7 years, 2 months ago by AITpro.

I setup a test server to reproduce this scenario and got things to “work” with open_basedir by simply using PHP RuntimeException conditions. Note: On my test server open_basedir works fine when I add only the path to the Root hosting account dir (Document Root) and the /tmp dir. So in order to reproduce the problem I had to misconfigure open_basedir to recreate the problem in order to find a solution. This “fix” will be added in the next BPS version. Note: There could be undesirable side-effects by doing this as I consider it kind of a workaround solution to a deeper root problem. The side-effects could include things like BPS will be unable to automatically setup the MScan Hosting Account Root Folders checkbox options on BPS upgrades and when running the Setup Wizard. That would simply mean that someone would need to manually select Hosting Account Root Folders checkbox options for folders that they wanted to scan.

I believe the root problem has to do with Symlinks, open_basedir and using Global $_SERVER['DOCUMENT_ROOT']. Using realpath() may be a solution.

realpath() expands all symbolic links and resolves references to ‘/./’, ‘/../’ and extra ‘/’ characters in the input path and returns the canonicalized absolute pathname.

If you look closely at the open_basedir error you will see the 2 dots at the end of path: /var/www/mysite/.., which is most likely caused by the Directory Iterator not skipping dots (. and ..) in the BPS code, which needs to be added in the BPS Iterator code. So 3 additional code changes need to be made: Skip Dots in the Interator code, use realpath() for the Global $_SERVER['DOCUMENT_ROOT'] and finally add the PHP RuntimeException conditions if things go south for any reason.

Oops ok Skip Dots is not needed since that code is already being used > ! $files->isDot(). So hopefully realpath() and adding PHP RuntimeException conditions will do the trick.

• This reply was modified 7 years, 2 months ago by AITpro.

Maybe open_basedir errors use the dots (..) figuratively and not literally? Not really sure since I try avoid open_basedir as much as possible. ??

Sounds like you’re in the process of figuring out a fix. Can I help in any way? Is there any more information I can provide?

I did see the ‘..’ path, which was why I was asking about /var/www (the directory referred to by ‘..’ in the example I provided).