Josiah Wallingford Posted April 11, 2018 Posted April 11, 2018 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.
Stuart Silvester Posted April 11, 2018 Posted April 11, 2018 11 hours ago, Josiah Wallingford said: 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.
bfarber Posted April 11, 2018 Posted April 11, 2018 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).
CheersnGears Posted April 11, 2018 Posted April 11, 2018 I'm getting it even though open_basedir is enabled.
Sirmadsen Posted April 11, 2018 Posted April 11, 2018 1 hour ago, CheersnGears said: I'm getting it even though open_basedir is enabled. Same here
Adlago Posted April 11, 2018 Posted April 11, 2018 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 ...
Chris Anderson Posted April 11, 2018 Posted April 11, 2018 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.
CheersnGears Posted April 12, 2018 Posted April 12, 2018 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.
jcdesign Posted April 12, 2018 Posted April 12, 2018 I am at VPS WHM / cPanel server and this warning is ridiculous.
CheersnGears Posted April 12, 2018 Posted April 12, 2018 9 hours ago, jcdesign said: 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.
Ocean West Posted April 13, 2018 Posted April 13, 2018 are there examples of the path that your suppose to use?
Rhett Posted April 13, 2018 Posted April 13, 2018 If you are running suphp and whm/cpanel, ignore this notice for the time being on beta.
ChrisVanMeer Posted April 14, 2018 Posted April 14, 2018 On 4/11/2018 at 3:16 PM, bfarber said: 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.
opentype Posted April 14, 2018 Posted April 14, 2018 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. ?
Josiah Wallingford Posted April 14, 2018 Author Posted April 14, 2018 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
opentype Posted April 14, 2018 Posted April 14, 2018 You need to allow the temp directory. The IPS security warning actually explains this.
Josiah Wallingford Posted April 14, 2018 Author Posted April 14, 2018 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.
Ocean West Posted April 15, 2018 Posted April 15, 2018 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.
ChrisVanMeer Posted April 15, 2018 Posted April 15, 2018 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
Woodsman Posted April 19, 2018 Posted April 19, 2018 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.
steve00 Posted April 19, 2018 Posted April 19, 2018 1 hour ago, Woodsman said: 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
CodingJungle Posted April 19, 2018 Posted April 19, 2018 On 4/11/2018 at 8:16 AM, bfarber said: 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?
Woodsman Posted April 19, 2018 Posted April 19, 2018 1 hour ago, steve00 said: 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.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.