open_basedir and what to do about it

Howtos, instructions and links to related software. Do not ask questions here.
feader
Bear Rating Master
Bear Rating Master
Posts: 160
Joined: 26 Dec 2012, 20:03

open_basedir and what to do about it

Postby feader » 30 Dec 2015, 16:16

A well-known issue open_basedir has is that it breaks curl's CURLOPT_FOLLOWLOCATION option, which anyones favorite feed reader software doesn't hack around anymore. Since there are already so many somewhat misleading (to say the least) articles on the web describing how to configure open_basedir, I thought that one more of the sort couldn't hurt.

Most of the pain happens when ttrss fetches the feeds and redirections don't happen anymore. If the CLI is used for this business, there is an easy remedy for that: Patch update.php with

Code: Select all

- passthru(PHP_EXECUTABLE . " " . $argv[0] ." --daemon-loop $quiet $log");
+ passthru(PHP_EXECUTABLE . " -d open_basedir=NULL " . $argv[0] ." --daemon-loop $quiet $log");

if the daemon is used (not tested for update_daemon2), or call

Code: Select all

php -d open_basedir=NULL update.php --feeds --quiet

for the cron option (not tested by me at all, so use this on your own risk).

If one of these suggestions works, the GUI may still have an nonempty open_basedir, which can hurt feed updates with SIMPLE_UPDATE_MODE or the feed debugger. To change it then, one probably needs access to global configuration files.
The case that is best documented 'round the web is when mod_php is used, see this and this for starting points, I couldn't test neither of them.

When php is used in CGI/FastCGI mode, php.ini sections are your best shot. Although hilariously underdocumented, I got lucky with using

Code: Select all

[HOST=ttrss.example.com]
open_basedir =

in a global ini file, where ttrss.example.com was the thing in my SELF_URL_PATH (hasn't any path components though).

Finally, our long nightmare seems to come to an end. After roughly 10 years, curl in its version 7.19.4 implemented something called CURLOPT_REDIR_PROTOCOLS which in php 5.6.0 or later, allows curl to follow redirections even when open_basedir is set (see here), but I couldn't test it yet.
The agility demonstrated makes me optimistic that come 2030, php's standard library will include a html5 parser.

To summarize: open_basedir is bad, and it should feel bad.

User avatar
fox
^ me reading your posts ^
Posts: 6318
Joined: 27 Aug 2005, 22:53
Location: Saint-Petersburg, Russia
Contact:

Re: open_basedir and what to do about it

Postby fox » 30 Dec 2015, 16:22

i'm not sure what's the point of going through all this trouble to disable this rather useless (and even harmful in that it provides people with false sense of security) kludge selectively instead of disabling it altogether

User avatar
fox
^ me reading your posts ^
Posts: 6318
Joined: 27 Aug 2005, 22:53
Location: Saint-Petersburg, Russia
Contact:

Re: open_basedir and what to do about it

Postby fox » 13 Jan 2016, 18:01

maybe a better approach would be disabling curl if open_basedir is set

curl-related plugins won't work but at least feeds are going to be updated properly

also, in general, i think screwing with security-related variables (even dumb ones) is not the best idea, someone possibly turned this on for a reason, we have to respect that


Return to “Knowledge Base”

Who is online

Users browsing this forum: No registered users and 2 guests