Re: Bytecode: Safe or not? / luac manual

[Sean Conner <sean@...>]

It was thus said that the Great Stefan Reich once stated:
>
> * Quite restrictive sandboxes. Java only offers a choice between
> "allow very little" and "allow anything". We want to be more flexible
> there, ultimately. Granted, this is a thing of future improvement.

  The problem you face is that the general case of moving code is unsolvable
(i.e. the Halting Problem).  As you restrict the cases, you move from
unsolvable to doable, but that's the issue---restrictions.  Putting aside
bytecode verification for a moment, take the following bit of code:

	function split(s,delim)
	  local results = {}
	  local delim   = delim or "%:"
	  local pattern = "([^" .. delim .. "]+)" .. delim .. "?"
	  
	  for segment in string.gmatch(s,pattern) do
	    table.insert(results,segment)
	  end
	  
	  return results
	end

  It's quite easy to transfer as bytecode (and assuming that string.gmatch()
and table.insert() are considered "safe" functions), but what about the
following:

	local gm = string.gmatch
	local ti = table.insert

	function split(s,delim)
	  local results = {}
	  local delim   = delim or "%:"
	  local pattern = "([^" .. delim .. "]+)" .. delim .. "?"

	  for segment in gm(s,pattern) do
	    ti(results,segment)
	  end

	  return results
	end

  Transferring the bytecode fails, as it now references two local variables
that aren't part of the split() bytecode stream.  You then need to not only
get the bytecode for split(), but check the number of upvalues (using
debug.getinfo()), extract them (debug.getupvalue()) and somehow construct a
chuck that contains the variables and the bytecode.

  Or you can restrict code that can be transferred to exclusing any upvalues
(a valid choice, I did that for a project where I had to transfer Lua
functions).

  But that's the case---in general, it's impossible.  There have to be
restrictions to make it viable.

  -spc (Never mind that you can't transfer modules written in C ... )