Controlling lua features

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Controlling lua features

Lloyd-2

Hi,
  Lets think that we want to embed lua to a windows service (daemon) like  
application. At the service startup, it executes the used given lua  
script. If the user supplies an "infinite useless empty loop" rest of the  
service will never be executed!! Is there any mechanism in lua to stop  
this kind of behavior? I mean, can I exclude loop kind of lua features, by  
making some settings in my lua configuration or someware?

Thanks,
   Lloyd

______________________________________
Scanned and protected by Email scanner
Reply | Threaded
Open this post in threaded view
|

Re: Controlling lua features

Patrick Donnelly
On Sat, May 9, 2009 at 4:44 AM, Lloyd <[hidden email]> wrote:
>
> Hi,
>  Lets think that we want to embed lua to a windows service (daemon) like
> application. At the service startup, it executes the used given lua script.
> If the user supplies an "infinite useless empty loop" rest of the service
> will never be executed!! Is there any mechanism in lua to stop this kind of
> behavior? I mean, can I exclude loop kind of lua features, by making some
> settings in my lua configuration or someware?

A simple google search yields answers to your question:

http://lmgtfy.com/?q=lua+execution+time+control

Such as:

http://lua-users.org/wiki/NonBlockingLuaExecution

--
-Patrick Donnelly

"Let all men know thee, but no man know thee thoroughly: Men freely
ford that see the shallows."

- Benjamin Franklin
Reply | Threaded
Open this post in threaded view
|

Re: Controlling lua features

Phoenix Sol
"lmgtfy.com"; that's great;
It's even more humiliating than 'RTFM'...
I'm surprised I haven't been chastised with it yet ;-)


On May 9, 2009, at 5:58 AM, Patrick Donnelly <[hidden email]>  
wrote:

> On Sat, May 9, 2009 at 4:44 AM, Lloyd <[hidden email]> wrote:
>>
>> Hi,
>>  Lets think that we want to embed lua to a windows service (daemon)  
>> like
>> application. At the service startup, it executes the used given lua  
>> script.
>> If the user supplies an "infinite useless empty loop" rest of the  
>> service
>> will never be executed!! Is there any mechanism in lua to stop this  
>> kind of
>> behavior? I mean, can I exclude loop kind of lua features, by  
>> making some
>> settings in my lua configuration or someware?
>
> A simple google search yields answers to your question:
>
> http://lmgtfy.com/?q=lua+execution+time+control
>
> Such as:
>
> http://lua-users.org/wiki/NonBlockingLuaExecution
>
> --
> -Patrick Donnelly
>
> "Let all men know thee, but no man know thee thoroughly: Men freely
> ford that see the shallows."
>
> - Benjamin Franklin
Reply | Threaded
Open this post in threaded view
|

Re: Controlling lua features

steve donovan
On Sat, May 9, 2009 at 2:57 PM, Phoenix Sol <[hidden email]> wrote:
> "lmgtfy.com"; that's great;
> It's even more humiliating than 'RTFM'...
> I'm surprised I haven't been chastised with it yet ;-)

Although I think Patrick has been a wee bit cruel to the poster. It's
actually a delicate issue, and the page he gives is a feature
proposal.

steve d
Reply | Threaded
Open this post in threaded view
|

Re: Controlling lua features

Phoenix Sol
Yeah, I could do without the cruelty myself. I'm sorry to have expressed amusement at it.

Let's not alienate one another!

...Or correct other's spelling errors; which I admit I'm guilty of. (My 'unscribe' / 'unsubscribe' joke... sorry....)
I promise I will endeavor to resist such 'cheap shots' in the future. (I understand that we aren't all native English speakers....)

Phoenix Sol


On Sat, May 9, 2009 at 8:37 AM, steve donovan <[hidden email]> wrote:
On Sat, May 9, 2009 at 2:57 PM, Phoenix Sol <[hidden email]> wrote:
> "lmgtfy.com"; that's great;
> It's even more humiliating than 'RTFM'...
> I'm surprised I haven't been chastised with it yet ;-)

Although I think Patrick has been a wee bit cruel to the poster. It's
actually a delicate issue, and the page he gives is a feature
proposal.

steve d

Reply | Threaded
Open this post in threaded view
|

Re: Controlling lua features

Duncan Cross
In reply to this post by steve donovan
On Sat, May 9, 2009 at 2:37 PM, steve donovan <[hidden email]> wrote:

> On Sat, May 9, 2009 at 2:57 PM, Phoenix Sol <[hidden email]> wrote:
>> "lmgtfy.com"; that's great;
>> It's even more humiliating than 'RTFM'...
>> I'm surprised I haven't been chastised with it yet ;-)
>
> Although I think Patrick has been a wee bit cruel to the poster. It's
> actually a delicate issue, and the page he gives is a feature
> proposal.
>
> steve d
>

It's also not always that straightforward Googling for Lua stuff
anyway, because there's still plenty of material on the 'net for older
versions of Lua that might or might not still apply to 5.1.

-Duncan
Reply | Threaded
Open this post in threaded view
|

Lua watchdog (Re: Controlling lua features)

Asko Kauppi

This was last discussed in February: http://lua-users.org/lists/lua-l/2009-02/msg00471.html


Duncan Cross kirjoitti 9.5.2009 kello 17:25:

> On Sat, May 9, 2009 at 2:37 PM, steve donovan <[hidden email]
> > wrote:
>> On Sat, May 9, 2009 at 2:57 PM, Phoenix Sol  
>> <[hidden email]> wrote:
>>> "lmgtfy.com"; that's great;
>>> It's even more humiliating than 'RTFM'...
>>> I'm surprised I haven't been chastised with it yet ;-)
>>
>> Although I think Patrick has been a wee bit cruel to the poster. It's
>> actually a delicate issue, and the page he gives is a feature
>> proposal.
>>
>> steve d
>>
>
> It's also not always that straightforward Googling for Lua stuff
> anyway, because there's still plenty of material on the 'net for older
> versions of Lua that might or might not still apply to 5.1.
>
> -Duncan

Reply | Threaded
Open this post in threaded view
|

Re: Controlling lua features

Patrick Donnelly
In reply to this post by steve donovan
On Sat, May 9, 2009 at 7:37 AM, steve donovan <[hidden email]> wrote:
> On Sat, May 9, 2009 at 2:57 PM, Phoenix Sol <[hidden email]> wrote:
>> "lmgtfy.com"; that's great;
>> It's even more humiliating than 'RTFM'...
>> I'm surprised I haven't been chastised with it yet ;-)
>
> Although I think Patrick has been a wee bit cruel to the poster. It's
> actually a delicate issue, and the page he gives is a feature
> proposal.

Actually that page highlights current solutions which gives plenty of
material for further study (and google searches). There are plenty of
places in the archives where this is also discussed (where more google
searches would lead him).

--
-Patrick Donnelly

"Let all men know thee, but no man know thee thoroughly: Men freely
ford that see the shallows."

- Benjamin Franklin
Reply | Threaded
Open this post in threaded view
|

Re: Controlling lua features

Philippe Lhoste
On 10/05/2009 02:52, Patrick Donnelly wrote:
> Actually that page highlights current solutions which gives plenty of
> material for further study (and google searches). There are plenty of
> places in the archives where this is also discussed (where more google
> searches would lead him).

Well, that's a FAQ (or a FEN - frequently expressed need) and I suppose
Lloyd, among others, hoped for a simple and definitive answer... :-)

"can I exclude loop kind of lua features"

I fear not. Well, tweaking the code, I suppose you can remove for, while
and repeat/until. But you would have also to remove function call
support (recursion).
But at this point, you better use Json or Yaml for configuration... :-D
So as said, a solution is to stop a long running Lua script.

--
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --

Reply | Threaded
Open this post in threaded view
|

Re: Controlling lua features

steve donovan
On Sun, May 10, 2009 at 10:08 AM, Philippe Lhoste <[hidden email]> 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"
            end
        end
    end
    local chunk,err = loadstring('return '..s,'tbl')
    if not chunk then return nil,err end
    setenv(chunk,{})
    return chunk()
end

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.
Reply | Threaded
Open this post in threaded view
|

Re[2]: Controlling lua features

Bulat Ziganshin
Hello steve,

Sunday, May 10, 2009, 5:45:10 PM, you wrote:

> WIthout the {} check, then people can call functions you provide, but
> can't write a loop.

s = "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
s = s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s
s = s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s
s = s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s
s = s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s..s
s = string.gsub(s, "!.*x","")

> 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.

the only safe way is use of windows thread and killing it

--
Best regards,
 Bulat                            mailto:[hidden email]