Page MenuHomePhabricator

Wiki system admins should be able to whitelist installed Lua libraries
Closed, DeclinedPublic

Description

The list of Lua libraries (and possibly, global functions) allowed to be required by Lua modules should be configurable by administrators:

  1. LuaSandbox should take this list from the PHP configuration file luasandbox.ini. At present, it is hardcoded into luasandbox/library.c;
  2. Scribunto should use a setting from LocalSettings.php not hardcoded in Scribunto/engines/LuaCommon/lualib/package.lua, or wherever else it is hidden.

The default values for these can stay as they are (string, math, etc.) but the final choice ought to belong to the admin.


Version: master
Severity: enhancement

Details

Reference
bz61432

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 2:58 AM
bzimport added a project: Scribunto.
bzimport set Reference to bz61432.
bzimport added a subscriber: Unknown Object (MLST).


The enclosed patch links two .so libraries for Lua to luasandbox. This is but a hack, far from what is desired. In particular, you need to know what libraries will be used before compilation. A better solution would be to link a library by a php function provided by luasandbox extension (just as dl () loads PHP extensions), in turn, called from Scribunto engine class; this function has to be wrapped up as a module loader in package.lua.

Anomie claimed this task.

Probably better not to make it easy to open random security holes.

Calls into PHP from luasandbox seem to have proven performant enough to handle extending Scribunto that the need for C extensions on the Lua side of things seems unlikely to be necessary, and adding features via MediaWiki extensions seems less likely to result in general incompatibilities between installations.

Some features are provided only by Lua libraries in C (.so). Do you know a way to link such a library via a call into PHP from luasandbox?

Not sure the wiki system admins (sysops?) should be allowed to add C-calls, but the argument that the current configuration is “have proven performant enough” seems dubious at best. We don't implement harder Lua code simply because Lua is capped – we lack performance.