lua-users home
lua-l archive

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


I totally agree with you. 

What I'm proposing is not drilling security holes into Lua. 

	1. Only the stand-alone lua interpreter would be affected (by
yet-another-standard-library ;). Not the language, not your embedding game
engine.

	2. If it's still an issue, the feature can be disabled easily (just
as loading libraries now is just comment/uncomment a single line).

	3. If it's still an issue, the default behaviour can even be
"switched off". Only if you go and enable that line, the "extension loading"
mechanism would become available.

I _know_ such packages already exist (I'll dig into them next week). The
problem for me as a newcomer is which package to select, since none is
official.

- Asko

--
Asko Kauppi
Flextronics Design Finland
Box 23, 39201 Kyröskoski, Finland
www.flextronics.com 
PGP: 8348 2AE1 CEDC C81A 2255  2439 E4C8 7308 825E 32C3


> -----Original Message-----
> From:	Sean Middleditch [SMTP:elanthis@awesomeplay.com]
> Sent:	Thursday, May 30, 2002 5:20 PM
> To:	Multiple recipients of list
> Subject:	RE: Can this be done?   (loading extensions from dlls / so's
> at r unti me)
> 
> I'd vote against it.  Loading libraries from a secondary source (or even
> allowing an 'include' directive) can be a security hole for scripts. 
> Lua scripts are meant to be embedded in an application.  If the
> application does not wish to allow the user scripts to access the system
> resources, or load outside/untrusted code, it shouldn't be allowed.  For
> example, game engines often download and run client scripts from a
> server (for example, in an FPS, when you connect to a server with a
> weapon mod, the scripts for the weapon special effects have to be
> downloaded and run on the client).  Now imagine if Lua was used, and
> including/loading outside scripts was allowed.  A common extension could
> be loaded that would grant the script "power" over the user account on
> the system.  This is the same reason I don't agree in providing built-in
> file system or other OS services to a scripting language.  Making it a
> secondary, outside feature allows applications to not only
> include/exclude only the features it wants, but also (assuming we are
> talking shared libraries/dll's) dynamically add and remove features at
> run time.
> 
> This is the approach I've taken with Scriptix.  The only other major
> feature I'd like to see in a script language (and which may be overkill
> for Lua) is a security priv's system.  For example, give the language
> file system functions, but require any thread/script that wishes to use
> them to have the "fs" privilege.  Then, scripts auto-downloaded and run
> from a server could be denied this privilege, while scripts that are
> pre-installed on the local system could be granted the fs privilege. 
> This way, connecting to a server can't (easily) compromise your system,
> while anything you manually downloaded and installed would have full
> access.  This feature could also be really useful in an application
> itself (for example, the scripts might require a "ui" privilege in order
> to alter the game's UI, or an "admin" privilege to control the game
> connections and so on).
> 
> Sean Etc.
> 
> On Thu, 2002-05-30 at 03:41, Asko Kauppi wrote:
> > 
> > As you can see from the thread, there's N solutions already for this...
> To
> > me, it seems like a thing that should be done "centrally" (= within the
> > Lua's built-in sample interpreter) and then no-one would need to have
> > secondary libraries doing the same thing.
> > 
> > I'll have a look at some of the proposed packages (TOMAS: please send me
> > yours!) and see if some of them matches my needs already. 
> > 
> > Thanks for all the tips! :)
> > 
> > - Asko
> > 
> > --
> > Asko Kauppi
> > Flextronics Design Finland
> > Box 23, 39201 Kyröskoski, Finland
> > www.flextronics.com 
> > PGP: 8348 2AE1 CEDC C81A 2255  2439 E4C8 7308 825E 32C3
> > 
> > 
> > > -----Original Message-----
> > > From:	Tomas [SMTP:tomas@rpa.vrac.puc-rio.br]
> > > Sent:	Wednesday, May 29, 2002 5:01 PM
> > > To:	Multiple recipients of list
> > > Subject:	Re: Can this be done?   (loading extensions from dlls / so's
> > > at runti me)
> > > 
> > > > 2. In the lua scripts run through that interpreter, they'd say "load
> > > > my_extensions.so" (or something like that), dynamically linking to
> the
> > > > functions etc. resources within the ".so".
> > > > 
> > > > This isn't possible with the current implementation, right?
> > > > 
> > > > If I do extensions, I have to complain the full lua engine into the
> app
> > > as
> > > > well. This might lead to situations where there are several engines
> > > > (probably of different version) on a system at once, each for a
> separate
> > > > task and with its own extensions. Somehow, I feel more at home if I
> had
> > > one
> > > > language engine and "libraries" (althoug implemented in C) for that.
> > > > 
> > > > Does anyone share these ideas and has this been discussed already?
> > > 	I've made a package with some libraries and a Makefile
> > > that modifies the distributed Lua interpreter to add the capability
> > > of loading dynamic libraries.  I've only tested it on Linux, but I
> > > think it runs on any Unix...
> > > 	I've been using it for exactly what you want: scripts
> > > that need some C libraries loaded dynamically.  The package includes
> > > LuaSQL, LuaSocket, MD5 and Poslib.  I can send you a copy if you ask
> me.
> > > 	On the other hand I don't know exactly if the method I've
> > > implemented will be compatible with the method adopted in the new
> > > version 5.0.  So, maybe you would prefer to wait for it.
> > > 
> > > 	Tomas
> > ###########################################
> > This message has been scanned by F-Secure Anti-Virus for Microsoft
> Exchange.
> > 
> 
> 
###########################################
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.