[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Sandboxing and thread environments
- From: William Ahern <wahern@...>
- Date: Thu, 10 Aug 2006 23:12:39 -0700
On Thu, 2006-08-10 at 20:46 -0700, William Ahern wrote:
> On Thu, 2006-08-10 at 20:12 -0700, William Ahern wrote:
> > On Thu, 2006-08-10 at 20:08 -0700, William Ahern wrote:
> > > So, I'm trying to sandbox a thread and I think I'm overestimating the
> > > ability of lua_setfenv(, [thread index]) to circumvent the lexical
> > > closure characteristics of Lua.
> > >
> > > Basically, what I _want_ is to create a process global Lua instance,
> > > against which I register all my C functions.
> > >
> > > Then, for each client (this is a server application), I want to create a
> > > sandboxed thread--chain the new env table to the old using the __index
> > > metatable trick--from which I will execute some Lua code.
> > >
> > > However, the only way that I can get the Lua code to see the sandboxed
> > > environment and not the main global environment is to actually load the
> > > code within the sandboxed thread. I had thought that Lua 5.1 would allow
> > > me to load the code, which when I call into the defined functions from
> > > the new thread those functions would see the sandboxed environment.
> >
> > I also tried using a function factory. And then a function factory
> > called through loadstring("genfunc()")(). No dice. I really thought that
> > would work, and so now I'm definitely more confused than not.
> >
>
> Huh. This _seems_ to work:
>
> function func_called_from_each_thread()
> setfenv(1, getfenv(0))
>
> ...
> end
>
Ack. This literally only localizes the function. Any function called
from within still doesn't see the thread's globals.
--
William Ahern <wahern@barracudanetworks.com>
--------------------------------------------------
This message was scanned for Spam, Spyware and Viruses
For more information, please visit:
http://www.barracudanetworks.com