lua-users home
lua-l archive

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

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
> PGP: 8348 2AE1 CEDC C81A 2255  2439 E4C8 7308 825E 32C3
> > -----Original Message-----
> > From:	Tomas []
> > 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
> > >" (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.