Last modified: 2011-04-14 15:13:36 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 11009 - open_basedir breaks use of external tidy
open_basedir breaks use of external tidy
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2007-08-20 19:06 UTC by Ted Pavlic
Modified: 2011-04-14 15:13 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Ted Pavlic 2007-08-20 19:06:52 UTC
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?
Comment 1 Chad H. 2008-12-05 17:26:25 UTC
Fixed in r11009 with adding of $wgNullFile. Can be overridden to whatever you'd like.
Comment 2 Brion Vibber 2008-12-10 22:58:46 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.