Page MenuHomePhabricator

open_basedir breaks use of external programs as it redirects some file descriptors to /dev/null
Open, LowPublic

Description

Author: ted

Description:
When MediaWiki shells out to external programs (e.g., tidy), it redirects some of the file descriptors to /dev/null.

If the open_basedir PHP option is turned on, this prevents the execution of the external program because /dev is not usually included in the open_basedir paths.

It seems like there should be other ways to discard output rather than opening /dev/null. Could one of those methods be used instead?


Version: 1.10.x
Severity: normal

Details

Reference
bz11009

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:51 PM
bzimport set Reference to bz11009.
bzimport added a subscriber: Unknown Object (MLST).

Fixed in r11009 with adding of $wgNullFile. Can be overridden to whatever you'd like.

(That was r44254 ...)

I've reverted this in r44428

Doesn't seem like a proper fix here... At best, this'll be dumping random crap to some random file unless the user has a local copy of the /dev/null device file, which seems.... wrong. :)

For anything generating command lines, it probably won't make any difference (assuming exec() is enabled at all!) since open_basedir won't be searching through the command line (I think).

Assuming the core use case actually happens (open_basedir is set, but proc_open() is available to run tidy), a more correct fix is probably to go ahead and read in stderr and toss the results, or maybe better pass it through to PHP's stderr FD instead of opening /dev/null ourselves. Tidy has a -q option which should suppress random "hi i'm tidy version XYZ" if it's currently present.

Aklapper renamed this task from open_basedir breaks use of external tidy to open_basedir breaks use of external programs as it redirects some file descriptors to /dev/null.Feb 15 2022, 10:27 PM
Aklapper removed a project: Tidy.