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

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T13009, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 11009 - open_basedir breaks use of external tidy
open_basedir breaks use of external tidy
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.10.x
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  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: ---


Attachments

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.


Navigation
Links