I just upgraded from 4.3 beta 3 to beta 4 and am now getting this message on my admin dashboard. Anybody know what this is or why I did not see this message in beta 3 but am now seeing it in beta 4? I do not have shared hosting.

  Quote

open_basedir not enabled
The open_basedir PHP configuration option is not enabled, which may be a security risk on shared hosting environments. We recommend setting it to your webroot and temporary directory. If you do not manage your server yourself, your hosting provider will be able to assist with this.

 

 

I just upgraded from 4.3 beta 3 to beta 4 and am now getting this message on my admin dashboard. Anybody know what this is or why I did not see this message in beta 3 but am now seeing it in beta 4? I do not have shared hosting.

 

There was a bug in Beta 3 where the message wouldn't be displayed, that was fixed in beta 4. It is a recommended security change.

More broadly - we used to have a separate "Security recommendations" page, but we've done away with that page and moved any security recommendations to the dashboard to make them more visible (and subsequently more actionable).

I'm getting it even though open_basedir is enabled. 

 

I'm getting it even though open_basedir is enabled. 

Same here

My host confirmed that open_basedir is enable.
Nonetheless, I added to that in php ini:

open_basedir = "/home/:/tmp"

This did not remove a message.
I added the same to in the admin folder php ini file and then a message has already been removed.
Strange ...

Works fine with me.

Although folks may indeed have added the appropriate open_basedir settings for their environment to their php.ini it is possible that their server is still working off of the old values.  You may have to initiate some kind of action to get your server to reload the updated php.ini file in order for the warning message to disappear.  I changed my php.ini file and my ACP still showed the warning message.  I stepped away for several hours and looked again and the warning message was gone.  My particular server seems to restart the web server periodically throughout the day and by doing so it used the new settings.   Your service provider should be able to readily steer you down the right path to get this new security setting enabled.

I've been down this rabbit hole most of the evening.  People on WHM/Cpanel and EasyApache4 are likely going to get very frustrated trying to fix this.

 I may end up just leaving it. 

I am at VPS WHM / cPanel server and this warning is ridiculous. 

 

I am at VPS WHM / cPanel server and this warning is ridiculous. 

Ditto.  I got it working, but it is definitely and outside the norm operation for WHM/Cpanel. It is very easy to break things getting this set up.

That said, I do think it is Cpanel's fault for not offering a way to properly configure it without manually editing the yaml files.

are there examples of the path that your suppose to use?

If you are running suphp and whm/cpanel, ignore this notice for the time being on beta.

 

More broadly - we used to have a separate "Security recommendations" page, but we've done away with that page and moved any security recommendations to the dashboard to make them more visible (and subsequently more actionable).

I for one would like to see it brought back. I don't like this big message on the dashboard.

Well, putting it on the dashboard is definitely working. We can tell from all the topics about people trying to set the additional security measures. ? 

When I have open_basedir enabled I am unable to upload attachments. I just get this error: 

  Quote

There was a problem processing the uploaded file. Please contact us for assistance.

I found this error in the server logs:

[14-Apr-2018 19:47:26 UTC] PHP Warning:  Unknown: open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (/home/sitedir/) in Unknown on line 0
[14-Apr-2018 19:47:26 UTC] PHP Warning:  File upload error - unable to create a temporary file in Unknown on line 0

 

You need to allow the temp directory. The IPS security warning actually explains this.

Okay, so I figured it out. Thank you opentype. 

Because I have the community installed in a sub directory of public_html I have two user.ini files where open_basedir is defined. I was trying to work with the public_html dir instead of directly within the community directory.

I think perhaps a list of example paths would be most helpful

after all there are examples for configuring cron jobs and also for piping email to the forums. 

I agree, some examples could be handy.
I mean, with cron jobs the system already outputs the path to php and the path of the site,
surely for open_basedir something simular can be created? That would be a real help  

I have multiple sites behind a DirectAdmin interface on a shared platform with just one php.ini file.
So when I am trying to get the open_basedir right, it messes up my production site  

same problem here...?

FYI - This is what I needed to to get it working. You need to reboot your server after making the php.ini changes to have them go into effect.

 

FYI - This is what I needed to to get it working. You need to reboot your server after making the php.ini changes to have them go into effect.

Which is fine if you are in control of your own server.

To the rest of us we have the hassle of contacting web host and asking them to re-start the server

Personally think there must be a better way to do this as far as recall never had this issue in any version up to and including 4.2.9 but now we have to in 4.3

 

More broadly - we used to have a separate "Security recommendations" page, but we've done away with that page and moved any security recommendations to the dashboard to make them more visible (and subsequently more actionable).

could they maybe get disabled on localhost or if in_dev is enabled?

 

Which is fine if you are in control of your own server.

To the rest of us we have the hassle of contacting web host and asking them to re-start the server

Personally think there must be a better way to do this as far as recall never had this issue in any version up to and including 4.2.9 but now we have to in 4.3

You need to reboot your server after making the php.ini changes to have them go into effect.

Obviously if you can't reboot your server yourself you need to contact your host.