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