Re: "*toclose" vs. sandboxes / embedded environments

[Patrick Donnelly <batrick@...>]

On Mon, Dec 17, 2018 at 8:59 AM Soni "They/Them" L. <fakedme@gmail.com> wrote:
>
>
>
> On 2018-12-17 2:51 p.m., Andrew Gierth wrote:
> >>>>>> "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.
> >
> where you'd use pcall/error you use coroutine.create+pcallk/yield
> instead. when it yields, throw it away, and you never(?) run the toclose
> that way.

Yields can be converted into errors (and caught) fairly easily:

> a = coroutine.wrap(function() print(pcall(string.gsub, "", "", function(a) coroutine.yield("foo") end)) end)
> a()
false   attempt to yield across a C-call boundar

-- 
Patrick Donnelly