Re: os.execute is scary;

[Jamie Webb <j@...>]

On Wednesday 28 January 2004 17:37, Paul Smith wrote:
> At 17:15 28/01/2004, you wrote:
> >>Almost all of the code is written purely in terms of the standard library
> >>(one or two routines use standard Unix command-line utilities via
> >>os.execute).
> >
> >os.execute and io.popen are scary functions.  When using them, you have to
> >be very certain about the contents of the strings being passed in. I'm
> >going to
>
> Whilst on that topic (or not), I thought I'd just mention what we've done
> here.
>
> We've modified the standard functions so that 'os.execute', 'os.popen' and
> some other things (eg os.open etc) are classed as 'sensitive' functions.
>
> A lua script can call a function 'io.enablesecurity("password")' which will
> disable all these functions, until 'io.disablesecurity("password")' is
> called.

Wouldn't a better solution be something like this:

function secure_wrapper(user_code, ...)
	local execute = os.execute
	os.execute = nil
	local r = user_code(unpack(arg))
	os.execute = execute
	return r
end

This adds no per-call overhead and seems to me to be more secure: there is no 
password to crack (or to run 'strings' on your code to find). Rather, the Lua 
semantics ensure that (provided you also class the debug functions as 
sensitive, and create no other accessible references to it), the user code 
cannot possibly obtain a reference to os.execute. Unless someone knows a 
sneaky way around that? You can allow you own code to access the sensitive 
functions even when called from the user code using closures:

do
	local execute = os.execute

	function my_code()
		execute("command")
	end
end

 -- Jamie Webb