lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Sun, May 10, 2009 at 10:08 AM, Philippe Lhoste <> wrote:
> Well, that's a FAQ (or a FEN - frequently expressed need) and I suppose
> Lloyd, among others, hoped for a simple and definitive answer... :-)

We definitely need one of those - I like 'Frequently Anticipated Questions'.

> "can I exclude loop kind of lua features"

The question is, what do your users need to do?

One answer to the 'supply configuration' need would be:

function read(s)
    if not s:find '^%s*%b{}%s*$' then return nil,"not a Lua table" end
    if s:find '[^\'"%w_]function[^\'"%w_]' then
        local tok = require ('pl.lexer').lua(s)
        for t,v in tok then
            if t == 'keyword' then
                return nil,"cannot have Lua keywords in table definition"
    local chunk,err = loadstring('return '..s,'tbl')
    if not chunk then return nil,err end
    return chunk()

This only allows a single table definition {...}, is completely
paranoid about the word 'function', and sets the function environment
to be empty, thus removing anything that could be dangerous. In this
case, I had a lexical scanner hanging around, so I used that if the
word 'function' was found in a unquoted form; Luiz' token filter patch
offers another solution. (I'm quoting this code because I'm curious if
anyone can think of a way of sneaking something nasty past this one)

The key to sandboxing is putting only the stuff you know to be safe in
the function environment. Then it is a matter of excluding the
keywords which can be abused, while, for, repeat and function.
WIthout the {} check, then people can call functions you provide, but
can't write a loop.  Looking for keywords can be a bit tricky, since
they _will_ appear in strings occaisionally, but can be done.

If you don't want to be too restrictive, then debug.sethook is
probably the way to go. Set it to callback every n (some large number)
of instructions and take appropriate action.

steve d.