Pentium 4 and misaligned doubles

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

Re: Simple Lua for scripts

Rici Lake-2

On 22-Aug-05, at 7:03 PM, Alain wrote:

What I really wanted is this: a much simpler scripting language than LUA, but I want LUA to execute it. Building a language is too complicated and LUA does it well. But Lua is too complex to leave in the hands of normal users, this is why: they will write things that don't work, then they will call ME to fix it.

Honestly, I think your best approach here is:

1) Trust your users. That may be hard, but it's worth it in the long run.

2) Admit to them when you don't understand what they're doing. Work through it with them, and you will both learn to program better.

Lua is actually a very simple language for beginning programmers. Possibly, it is more difficult for people who already have a fixed idea of how languages work.


Reply | Threaded
Open this post in threaded view
|

Re: Simple Lua for scripts

Chris Marrin
In reply to this post by Rici Lake-2
Rici Lake wrote:

...
It is perhaps slightly surprising that sandboxing Lua is quite simple, compared with other scripting languages. I hope that this feature will continue to receive high priority as the Lua packaging system develops.

Speaking of which, has anyone done any work on a "sandboxed" version of the os library? Something that constrains what the user can do to a set of directories or a set of restrictive permissions, or even one that prevents writing entirely. If this were a drop-in replacement for the os library, it could help a lot with this sort of sandboxing.

--
chris marrin                ,""$,
[hidden email]          b`    $                             ,,.
                        mP     b'                            , 1$'
        ,.`           ,b`    ,`                              :$$'
     ,|`             mP    ,`                                       ,mm
   ,b"              b"   ,`            ,mm      m$$    ,m         ,`P$$
  m$`             ,b`  .` ,mm        ,'|$P   ,|"1$`  ,b$P       ,`  :$1
 b$`             ,$: :,`` |$$      ,`   $$` ,|` ,$$,,`"$$     .`    :$|
b$|            _m$`,:`    :$1   ,`     ,$Pm|`    `    :$$,..;"'     |$:
P$b,      _;b$$b$1"       |$$ ,`      ,$$"             ``'          $$
 ```"```'"    `"`         `""`        ""`                          ,P`
"As a general rule,don't solve puzzles that open portals to Hell"'

Reply | Threaded
Open this post in threaded view
|

Re: Simple Lua for scripts

Alain
In reply to this post by Rici Lake-2


Rici Lake escreveu:

You've been told how to do this, several times.

Sorry, it may look like that, but I felt that the question was misunderstood. So I kept on asking and thanks to that, your answer bellow is close to what I need ;-)

For this I believe I need something called a lexical analyser, so that I can allow only a sunset of normal LUA syntax.
Perhaps you should think about the possibility that your belief is incorrect.

I can easyly accept that, thanks for your patiance so far. Please help me find my way.

A lexical analyzer will not tell you which Lua functions a program is using. However, you can arrange for only the functions you truly trust to be available in the Lua runtime.

That is really what I mean. Thanks for understanding me :)) even if you say that I am wrong. The question now is: How do I do it? I am reading about Lex+Yacc+Bison, I hope it can help.

If the function is not loaded into the Lua runtime (or if it is deleted) then it is no longer available. Period.

This is another very important idea. I am planing a static link, so I believe that it would be easy.

It is perhaps slightly surprising that sandboxing Lua is quite simple, compared with other scripting languages. I hope that this feature will continue to receive high priority as the Lua packaging system develops.

I am not sure that sandboxing can help me: I will have one lua state for each screen, many objects will have scripts that are executed according to screen events and may affect variables global to that screen/Lua-state. This should be protection enough because the sum of those events make the application. If I sandbox one script, it will not interact with the rest of the screen, at least this is what I understand.

Alain


Reply | Threaded
Open this post in threaded view
|

Re: Simple Lua for scripts

Alain
In reply to this post by Nick Trout


Nick Trout escreveu:

using. However, you can arrange for only the functions you truly trust to be available in the Lua runtime. If the function is not loaded into the Lua runtime (or if it is deleted) then it is no longer available. Period.

As I said in my former massage, this is a very good idea that I will implement, and as I will static link everything, it will be *safe*.

Alain, I do agree with you somewhat, that it would be nice to be able to
detect more of what a user is doing at compile time.

I am thinking a little befor that: at edit time.

I'm thinking more
in terms of misspelled objects etc calls rather than security issues,
which aren't impossible to detect, but current require parsing of the VM
code (and not all instances are easy to detect, as per the previous
examples).

This is a common complaint for people scripting in Lua (well in dynamic
languages, not just Lua) that easy mistakes aren't picked up until
runtime, whereas a statically compiled language would have picked this
up in the compile or link phase. This isn't such a problem if you have a
little script that executes and exits in 2 seconds, but if you have a
larger script that drives something and takes 5 minutes to hit a
spelling mistake, it can be irritating.

Yes

Work on "Lua macros" might fix both these issues. In your case you could
look for calls and box them, and my case I could check global object
lookups, where possible. It would also be possible to restrict the
syntax, where perhaps "extra syntax" is not necessary.

Restricting the syntax is what I am talking about. I would really appreciate a more strict syntax, even one that doesn't give access to full Lua functionality, not nly functions.

So another option would be to look at the LHFs ltokens library:
	http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/

Looks interesting, but hard to get from there to an analyzer ;-)

thanks all,
Alain

Reply | Threaded
Open this post in threaded view
|

Re: Simple Lua for scripts

Rici Lake-2
In reply to this post by Alain

On 22-Aug-05, at 7:38 PM, Alain wrote:

I am not sure that sandboxing can help me: I will have one lua state for each screen, many objects will have scripts that are executed according to screen events and may affect variables global to that screen/Lua-state. This should be protection enough because the sum of those events make the application. If I sandbox one script, it will not interact with the rest of the screen, at least this is what I understand.

That is one definition of sandbox, but the one that is being used here is a rather simpler one. We're not talking about separating two different environments. We're talking about setting up one environment, which is a protected environment. A sandbox.

There are two easy things you can do:

First, don't load libraries you don't need. Then no-one can use them. If you don't want any os interfaces, or any io, then simply take out the call to luaopen_os. Take out luaopen_debug. Then the functions plain and simply do not exist.

Alternatively, if you want to still let them call os.clock, but you don't want them to call os.system, just execute this code before you run any script:

os.system = nil

Then it's gone. (Or you could edit it out of the luaL_reg structure in the source code, so that it was never there in the first place.)

you can remove an entire library that way:

os = nil

So put down that book on yacc :) and just do it the simple way.


Reply | Threaded
Open this post in threaded view
|

RE: Simple Lua for scripts

Richard Ranft
In reply to this post by Alain
> What I really wanted is this: a much simpler scripting language than
> LUA, but I want LUA to execute it. Building a language is too
> complicated and LUA does it well. But Lua is too complex to leave in the
> hands of normal users, this is why: they will write things that don't
> work, then they will call ME to fix it.
>

My answer to this is -

Explicitly disclaim support for user scripts.  Or, explicitly state you will
charge some ridiculous amount of money to fix user scripts - it is custom
programming after all.

Or is this for some internal company tool?  If that's the case, simply tell
them to look up their mess in PiL - it's freely available.  Unless your job
description includes teaching every ninny at work how to program....

Any way you look at it, there is no way on Earth you can prevent a user from
writing buggy code.  Erase the thought from your mind.  It is absolutely,
positively and in all other ways inconceivable.  You CANNOT possibly predict
every last mistake, typo or lame-brained scheme that your users will dream
up.  So, your best bet is to forget it and take the solution offered.  Save
yourself!  Save your sanity!

Richard

"This was supposed to be fool-proof, but the fools are so damned ingenius!"


Reply | Threaded
Open this post in threaded view
|

Re: Simple Lua for scripts

Alain
In reply to this post by Rici Lake-2


Rici Lake escreveu:

So put down that book on yacc :) and just do it the simple way.

No so fast... What you said is perfect for security and I will include it. Simple and easy :)

But there remains on problem: I want to present users with a more simple syntax for the language. Not only for simplicity but for discipline too. There must be a way to do it.

You sai in another message: "Trust your users. That may be hard, but it's worth it in the long run." Well I don't trust them, it is sad but it is a fact of life: users are dangerous, agressive creatures.

As For sandboxing, I understand that I can apply this principle for the whole screen, am I correct? This way, the whole application will be safer, or if I remove all dangerous functions is enough?

Alain

Reply | Threaded
Open this post in threaded view
|

Re: Simple Lua for scripts

vol-lu
In reply to this post by Alain
Alain wrote:
> What I really wanted is this: a much simpler scripting language than
> LUA, but I want LUA to execute it. Building a language is too
> complicated and LUA does it well. But Lua is too complex to leave in the
> hands of normal users, this is why: they will write things that don't
> work, then they will call ME to fix it.

Well, perhaps LUA isn't what you're looking for then.  Writing a very
simple VM isn't very difficult depending upon your experience.  LUA is
essentially a stack-based VM with a large amount of opcodes.  Writing
a VM with very few opcodes may be something to consider.  This is a little
off-topic, but for a project a while back, I wrote a very small stack-based
VM which had only 3 opcodes.  PUSH, POP and CALL.  The CALL opcode called
an internal function referenced by an offset, and any items remaining on
the stack were used as output strings.  Sorry if this a little OT, but
in some situations, you need to know when you need to try a different
language/tool.

So, perhaps LUA isn't what you're looking for, or maybe you just need
to work harder to make it easier for the end-user, or perhaps you need
to throw together more documentation for the user.

Good luck!


Reply | Threaded
Open this post in threaded view
|

Re: Simple Lua for scripts

Rici Lake-2
In reply to this post by Alain

On 22-Aug-05, at 8:31 PM, Alain wrote:



Rici Lake escreveu:
So put down that book on yacc :) and just do it the simple way.

No so fast... What you said is perfect for security and I will include it. Simple and easy :)

But there remains on problem: I want to present users with a more simple syntax for the language. Not only for simplicity but for discipline too. There must be a way to do it.

Sure. You could write your own language. But I have a hard time figuring out what could be simpler than Lua. What syntactic constructs would you like to eliminate? (I emphasize the word syntactic here -- I understand the issue with spelling errors on global variables. That one is actually pretty simple to detect; the easiest way is to compile the function and then run it through luac and look for GETGLOBAL/SETGLOBAL lines. Or you could just copy the luac printing code; it's pretty straightforward.)


You sai in another message: "Trust your users. That may be hard, but it's worth it in the long run." Well I don't trust them, it is sad but it is a fact of life: users are dangerous, agressive creatures.


If you really feel that way, then I would advise that you get out of tech support. The pay's lousy and the work's repetitive. The only reward is the joy of helping people learn, and if you don't find joy in that, neither will they, and you'll all end up frustrated. Trust me on this -- I spent a lot of years doing tech support, and I miss it sometimes, but I saw a lot of my coworkers get really frustrated, and unnecessarily so. I personally *hate* the word "users"; I always made a point of saying "colleagues". Which I suspect was another frustration for my colleagues in tech support.

As For sandboxing, I understand that I can apply this principle for the whole screen, am I correct? This way, the whole application will be safer, or if I remove all dangerous functions is enough?

Every time you do a lua_open (i.e. every screen), you need to load a set of libraries. Presumably, you will do this with some wrapper function, so it should be easy to customise. Edit the list of libraries and/or edit the luaL_reg's of functions which they install. This is also where you will install your own functions and globals. Whatever you put into the Lua state is all there is; lua_open does not install a single function.

If all the scripts for a screen are written by the same user, it shouldn't be necessary to sandbox them from each other, as you say. In fact, it might be useful to them to be able to use globals (you can, however, give each script a separate globals table if that's useful to you).


Reply | Threaded
Open this post in threaded view
|

Re: Simple Lua for scripts

Alain
In reply to this post by Richard Ranft


Richard Ranft escreveu:
My answer to this is -
Explicitly disclaim support for user scripts.  Or, explicitly state you will
charge some ridiculous amount of money to fix user scripts - it is custom
programming after all.

That is ok and most of the time works. Users most of the time have a way of transforming a situation, and then is when I don't trust them.

If a user can say: "The specs say it is Lua code, this is Lua code so it should work for you too". That is when they get most agressive. When I can say that it isn *not* lua, but something with special limitation and if I can enforce such limitations, then I *can*trust* the users because they have no ground for argueing.

In the last years, I learned some interesting things about users: if they thing that they will get away with it, they will try to break it. If they feel that you can catch them (audit logs, video recordings) then they don't even try.


"This was supposed to be fool-proof, but the fools are so damned ingenius!"

:)

Alain

Reply | Threaded
Open this post in threaded view
|

Re: Simple Lua for scripts

Alain
In reply to this post by Rici Lake-2


Rici Lake escreveu:

Sure. You could write your own language. But I have a hard time figuring out what could be simpler than Lua. What syntactic constructs would you like to eliminate? (I emphasize the word syntactic here -- I understand the issue with spelling errors on global variables.

I hope I don't have to write my own language :)

> That one is actually
pretty simple to detect; the easiest way is to compile the function and then run it through luac and look for GETGLOBAL/SETGLOBAL lines. Or you could just copy the luac printing code; it's pretty straightforward.)

I will have a look.

You sai in another message: "Trust your users. That may be hard, but it's worth it in the long run." Well I don't trust them, it is sad but it is a fact of life: users are dangerous, agressive creatures.
If you really feel that way, then I would advise that you get out of tech support. The pay's lousy and the work's repetitive. The only reward is the joy of helping people learn, and if you don't find joy in that, neither will they, and you'll all end up frustrated. Trust me on this -- I spent a lot of years doing tech support, and I miss it sometimes, but I saw a lot of my coworkers get really frustrated, and unnecessarily so. I personally *hate* the word "users"; I always made a point of saying "colleagues". Which I suspect was another frustration for my colleagues in tech support.

Well, not that much. I *like* helping people that can understand what I say. What I don't like is that repetitive amount of stupid questions, but I have doing a fair amout of it lately and I dicovered (see my last message) that if things a planned better, support is a lot better do do and more effective. And then I can keep to backgroung support which I like.

I can say it now this way: I want to plan in advance so that conditions are better defined and so fewer error could happen. One way of doing it is by checking that the code corresponds to some arbitrary subset of the language.

As For sandboxing, I understand that I can apply this principle for the whole screen, am I correct? This way, the whole application will be safer, or if I remove all dangerous functions is enough?


Every time you do a lua_open (i.e. every screen), you need to load a set of libraries. Presumably, you will do this with some wrapper function, so it should be easy to customise. Edit the list of libraries and/or edit the luaL_reg's of functions which they install. This is also where you will install your own functions and globals. Whatever you put into the Lua state is all there is; lua_open does not install a single function.

If all the scripts for a screen are written by the same user, it shouldn't be necessary to sandbox them from each other, as you say. In fact, it might be useful to them to be able to use globals (you can, however, give each script a separate globals table if that's useful to you).

Yes, a screen is allways written by one user (hopefully) and thought of a one unit (has to be). I thing that I understand this now and will keep it for more tests.

thanks for all this discussion. Tomorow I will list all important topics that came as fruits from it,

Alain

Reply | Threaded
Open this post in threaded view
|

Re: Simple Lua for scripts

Zachary P. Landau-4
In reply to this post by Alain
All,

Related to this, some of you might find lua-safe[1] interesting.  I
posted it on the mailing list before but it seems relevant to this
topic.  It hasn't seen any real use, but those who are interesting
might want to check it out.

[1] http://divineinvasion.net/lua-safe/index.html

-- 
Zachary P. Landau <[hidden email]>


Reply | Threaded
Open this post in threaded view
|

purpose of threads?

Brent Arias
In reply to this post by Alain
Rici said:

"The main purpose of running multiple (Lua) threads in multiple (OS)
threads would be to allow the threads to communicate..."

Lets turn this around.  What is the main purpose of running multiple (Lua)
threads in an OS single-threaded environment?

The only reason I can think - is perhaps you want to have duplicate variable
contexts.  I mean, maybe you have a single lua script used to control
multiple instances of a helicopter.

And perhaps a corollary is this: the main purpose of coroutines in a OS
single-threaded environment, is if you need the appearance of concurrency
**AND** you don't need "a single lua script used to control multiple
instances of a helicopter".

Is this correct?

-Brent



Reply | Threaded
Open this post in threaded view
|

Re: Simple Lua for scripts

Philippe Lhoste
In reply to this post by Alain
Alain wrote:
But there remains on problem: I want to present users with a more simple syntax for the language. Not only for simplicity but for discipline too. There must be a way to do it.

Uh? Lua syntax is amongst the easier for the scripting languages I know (I don't know that much, but even :-)

I am not even sure a Basic dialect could be said easier. (Basic has been designed for beginners, after all.)

You sai in another message: "Trust your users. That may be hard, but it's worth it in the long run." Well I don't trust them, it is sad but it is a fact of life: users are dangerous, agressive creatures.

Well, so don't put a programming language in their hands, or generate code yourself, eg. with a graphical interface allowing to connect boxes to form an organigram (or an UML graph...).

Perhaps a bit like that: http://www.gemtree.com/editor.gif

Or make a simplistic metalanguage, and parse it to generate Lua code (or VM bytecode if you are good enough).

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

Reply | Threaded
Open this post in threaded view
|

Re: Simple Lua for scripts

Robert Raschke-2
In reply to this post by Alain
Alain (referencing Rici) wrote
> You sai in another message: "Trust your users. That may be hard, but 
> it's worth it in the long run." Well I don't trust them, it is sad but 
> it is a fact of life: users are dangerous, agressive creatures.

This reminds me of a quote I like to wheel out once in a while.  In my
opinion, Lua allows you to do the right thing(TM).


<blockquote>
Pretty graphical interfaces are commonly called "user-friendly." But
they are not really your friends.  Underlying every user-friendly
interface is a terrific human contempt.

The basic idea of a graphical interface is that it does not allow
anything alarming to happen.  You can pound on the mouse button all
you want, and the system will prevent you from doing anything stupid
...

To build such a crash-proof system, the designer must be able to
imagine - and disallow - the dumbest action.  He or she cannot simply
rely on the user's intelligence: who knows who will be on the other
side of the program?  Besides, the user's intelligence is not ...
programmable; it cannot protect the system.  No, the real task is to
forget about the intelligent person on the other side and think of
every single stupid thing anyone might possibly do.

In the designer's mind, gradually, over months and years, there is
created a vision of the user as imbecile.  The imbecile vision is
mandatory.  No good, crash-proof system can be built except it be
done for an idiot ...

The prettier the user interface, and the fewer odd replies the system
allows you to make, the dumber you once appeared in the mind of the
designer.
</blockquote>

-- Ellen Ullman, "Out of Time:  Reflections on the
Programming Life," in Brook and Boal, _Resisting the
Virtual Life_.  San Francisco,  City Lights, 1995.


Robby


Reply | Threaded
Open this post in threaded view
|

Re: Simple Lua for scripts

Klaus Ripke
In reply to this post by vol-lu
On Mon, Aug 22, 2005 at 08:50:09PM -0500, [hidden email] wrote:
> Well, perhaps LUA isn't what you're looking for then.  Writing a very
> simple VM isn't very difficult depending upon your experience.  LUA is
> essentially a stack-based VM with a large amount of opcodes.  Writing
or, for that matter, a register based VM

> a VM with very few opcodes may be something to consider.  This is a little
> off-topic, but for a project a while back, I wrote a very small stack-based
> VM which had only 3 opcodes.  PUSH, POP and CALL.  The CALL opcode called
> an internal function referenced by an offset, and any items remaining on
> the stack were used as output strings.  Sorry if this a little OT, but
> in some situations, you need to know when you need to try a different
> language/tool.
No problem, we do have Ook! perfectly well suited for Orang Utans.
Yet it is turing complete, and if it outputs to some xterm
with dangerous escape sequences (like open logfile) it can do
a lot of damage which you'd never figure out.

In addition to using sandboxing you need full output cleaning
and hard limits on memory and CPU usage. So you want to run user
code in a subprocess, because there is hardly another way to cope
with excess ressource usage than to kill it.


cheers

Reply | Threaded
Open this post in threaded view
|

Re: Simple Lua for scripts

David Given
On Tuesday 23 August 2005 09:30, many people wrote:
> Lots of messages about sandboxing Lua

Wee! 40 messages waiting for me when I get in to work!

The reason why I'm posting this is that I've noticed that nobody's actually 
explained the following yet, which may help to clarify things slightly.

There are two parts to Lua; there's the language (if...then...end, 
while...end, function...end, etc), and there are the libraries (print, 
math.sin, io.open, etc). The Lua *language* has zero functionality for doing 
anything without the libraries. As all the libraries are accessed via global 
variables, and the set of global variables a piece of code has access to can 
be easily changed, this means that the set of available libraries is 
trivially customisable. This means that it's possible to remove *all* ways 
that a Lua script can interact with the outside world, by simply removing the 
set of available libraries.

This Lua program:

  script = io.read("*all")   -- read in text from stdin
  chunk = loadstring(script) -- compile into an executable Lua chunk
  setfenv(chunk, {})         -- completely empty the chunk's globals

  status, result = pcall(chunk) -- execute the chunk
  print("status=", status, " result=", result)

...implements a safe Lua interpreter. It will execute the Lua program given in 
stdin in a sandboxed environment; the only way the sandboxed program has of 
interacting with the outside world is to return a value --- try it. If you 
can break it, the devs here would love to know because it's a major bug. 
It'll even execute invalid Lua code safely, returning the error that occurred 
so your program can deal with it.

(Typically you wouldn't do the above, because there are a number of safe 
functions that all Lua programs use; tonumber(), tostring(), type(), 
unpack(), math, table, etc. You'd want to provide these to the sandboxed 
program.)

This *doesn't* put limits on CPU time and memory usage, but you can do that 
fairly easily by using the C API --- you'd set a timer that, when fired, 
would cause the sandboxed program to be terminated. By putting a bound on the 
amount of CPU time you automatically put a bound on the amount of memory, but 
that can be customised as well.

Does this help?

-- 
+- David Given --McQ-+ "...it's not that well-designed GUI's are rare,
|  [hidden email]    | it's just that the three-armed users GUI's are
| ([hidden email]) | designed for are rare." --- Mike Uhl on a.f.c
+- www.cowlark.com --+ 

Attachment: pgpH25izp1jsD.pgp
Description: PGP signature

Reply | Threaded
Open this post in threaded view
|

Re: Simple Lua for scripts

Jamie Webb-3
In reply to this post by Alain
On Mon, Aug 22, 2005 at 10:58:25PM -0300, Alain wrote:
> That is ok and most of the time works. Users most of the time have a way 
> of transforming a situation, and then is when I don't trust them.
> 
> If a user can say: "The specs say it is Lua code, this is Lua code so it 
> should work for you too". That is when they get most agressive. When I 
> can say that it isn *not* lua, but something with special limitation and 
> if I can enforce such limitations, then I *can*trust* the users because 
> they have no ground for argueing.
> 
> In the last years, I learned some interesting things about users: if 
> they thing that they will get away with it, they will try to break it. 
> If they feel that you can catch them (audit logs, video recordings) then 
> they don't even try.

So, replace all the 'dangerous' functions with:

function os.execute()
	emailSysAdmin()
	print [[
This function is disabled. You are very bad for trying to use it. The
system administrator has been notified. Big brother is watching.
]]
end

If you run Lua with a sandbox, it /is/ a restricted version and you
/can/ enforce that. And you /can/ tell your users it's a restricted
version. Why are you so convinced that sandboxing won't do what you
want?

-- Jamie Webb

Reply | Threaded
Open this post in threaded view
|

Re: Simple Lua for scripts

Benno
On Tue Aug 23, 2005 at 12:41:36 +0100, Jamie Webb wrote:
>On Mon, Aug 22, 2005 at 10:58:25PM -0300, Alain wrote:
>> That is ok and most of the time works. Users most of the time have a way 
>> of transforming a situation, and then is when I don't trust them.
>> 
>> If a user can say: "The specs say it is Lua code, this is Lua code so it 
>> should work for you too". That is when they get most agressive. When I 
>> can say that it isn *not* lua, but something with special limitation and 
>> if I can enforce such limitations, then I *can*trust* the users because 
>> they have no ground for argueing.
>> 
>> In the last years, I learned some interesting things about users: if 
>> they thing that they will get away with it, they will try to break it. 
>> If they feel that you can catch them (audit logs, video recordings) then 
>> they don't even try.
>
>So, replace all the 'dangerous' functions with:
>
>function os.execute()
>	emailSysAdmin()
>	print [[
>This function is disabled. You are very bad for trying to use it. The
>system administrator has been notified. Big brother is watching.
>]]
>end
>
>If you run Lua with a sandbox, it /is/ a restricted version and you
>/can/ enforce that. And you /can/ tell your users it's a restricted
>version. Why are you so convinced that sandboxing won't do what you
>want?

Everyone here seem to be missing what the OP wants, which is that they
want to change the *syntax* of Lua, not the functions a user can
access.[*]

So, for example the probably don't want them defining function, or using
loops.

Of course, I agree with the other replies that this probably isn't something
that can easily be done in Lua.


Cheers,

Benno

[*] Disclaimer: I could of course be wrong, but that was the impression I got
when reading the original posts.

Reply | Threaded
Open this post in threaded view
|

Re: Simple Lua for scripts

Lisa Parratt
In reply to this post by Jamie Webb-3
Jamie Webb wrote:
function os.execute()
	emailSysAdmin()
	print [[
This function is disabled. You are very bad for trying to use it. The
system administrator has been notified. Big brother is watching.
]]
end

Shouldn't that be more along the lines of

function os.execute()
	user.cubicle.seal("hermetically")
	print("Executing user")
	user.chair.electrify(true)
	while (user.lifesigns ~= nil)
		user.cubicle.pump("cyanide", "gas")	
	end
	user.chair.electrify(false)
	user.cubicle.pump("air", "gas")
	user.cubicle.unseal()
	return true
end

? >;D

--
Lisa
http://www.thecommune.org.uk/~lisa/

123