[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: "*toclose" vs. sandboxes / embedded environments
- From: Andrew Gierth <andrew@...>
- Date: Mon, 17 Dec 2018 16:51:02 +0000
>>>>> "Roberto" == Roberto Ierusalimschy <roberto@inf.puc-rio.br> writes:
>> The problem for me is that if the Lua code does anything that raises
>> a PostgreSQL error, I have to limit what further calls happen to
>> other backend functions until some subtransaction level that
>> encloses the error is properly aborted and released. At present, I
>> can do that easily because Lua code has no way to catch errors
>> except for pcall(), and I replace the normal pcall() function with
>> one that creates a subtransaction, lua_pcall's the specified
>> function, and releases the subtransaction on either return or error
>> (and before calling the supplied error handler in the case of
>> xpcall). This guarantees that the Lua code can not do anything
>> unsafe in between the generation of the error and its being cleaned
>> up.
Roberto> What about Sony's suggestion, of running the sandboxed code
Roberto> inside a coroutine and using yields to stop the code? (BTW,
Roberto> that seems a good practice for any sandbox, independently of
Roberto> this to-be-closed issue.)
I'm not sure that helps. It certainly presents a problem of how to
unwind the C stack safely, especially in the case where Lua code has
called a C function that calls a Lua callback.
--
Andrew.