Re: "*toclose" vs. sandboxes / embedded environments
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: "*toclose" vs. sandboxes / embedded environments
- From: Andrew Gierth <andrew@...>
- Date: 2018年12月17日 22:14:27 +0000
>>>>> "Patrick" == Patrick Donnelly <batrick@batbytes.com> writes:
Patrick> Yields can be converted into errors (and caught) fairly
Patrick> easily:
That makes a good concrete example actually. Suppose the user does
something like this, replacing words in a string with words looked up
via an SQL query:
CREATE FUNCTION subst_words(str text) RETURNS text LANGUAGE pllua AS $$
return str:gsub("%w+",
function(w)
local nw = spi.execute([[ SELECT newword
FROM replacewords
WHERE oldword=1ドル ]], w)
return nw and nw[1] and nw[1].newword
end)
$$;
Right now, if spi.execute gets an error generated by PG, what happens is
that it stores the relevant details in a userdata, throws that as a Lua
error, lets it propagate out to the lua_pcall that was used to call the
function, and then raises it as a PG error again. There could be several
levels of this - for example, the SQL query might contain a call to
another Lua function. (It doesn't matter if the error gets replaced with
a different error along the way, for example if we get an out-of-memory
when trying to copy error data, as long as it continues to propagate as
an error and as long as we're not executing arbitrary Lua code.)
I can be sure this is safe because the Lua code can't interfere with the
error process except by calling pcall()/xpcall(), which I already
replaced with my own versions.
But in the new version, as far as I can tell, I can either use a
coroutine - which in the above example means I can't unwind the C stack
safely thanks to the gsub call - or stick with the existing model, in
which case I have to expect that arbitrary Lua code can be executed
during error handling, with no way for me to control what's happening.
--
Andrew.