Celestia Forums

Should Celestia's implementation of Lua (it's new Celx scripting language) include the ability to read and write files, access system information (OS type, time, etc.), and allow a script to run an external program (ie. audio file playback, Java pop-up information windows, etc.)? This would be considered a full implementation of Lua. Currently, Celestia does not include these capabilities in it's implementation of Lua/Celx.

The idea would be to provide entries in Celestia's configuration file that would allow the user, and not Celestia, to make their own choice about allowing or disallowing these options on their computer, much like Internet Explorer and other browsers do for Java. For example:

* Allow scripts to read & write files? (Enable, Disable, Prompt)
* Allow scripts to run external programs? (Enable, Disable, Prompt)
(Default value for both is Disable.)

When Prompt is selected, Celestia would pop-up a warning box when one of the potentially dangerous Lua commands is about to be executed (write a file, run a program, etc.) displaying the command, and asking the user if they want to continue running the script or cancel it.

Would this be a security risk? Yes, but no more than enabling Java, ActiveX controls or scripting in your browser. It is up to YOU, the user, to make an educated decision to run a script or to not run a script.

Don,
I think this is a great idea as long as the dialog will tell exactly what a script is trying to do. Would I be able to tell, "Oh it writes a file saving my time and location in Celestia to open later, or does it format my hard drive and email my credit card numbers to Nigeria?" Will the dialog reflect the action the script is trying to perform or will the script writer be able to just put in a string so that is ask for one thng but does another?

Joe

alphaplus,

I think it's up to this discussion to decide that. On my opinion a popup would simply display the Lua command line that's going to be executed.

maxim

Personally, I would like to see the pop-up display the command, file and path. For example:



If the user has not looked at the script prior to running it, this information should provide them with enough information to locate the file that will be written to or run, and determine whether or not to allow this command to execute.

Some comments from a technical point of view:
- I am not sure if the os and io commands can be activated seperately, as both are defined in the same lua library. It may be possible to remove the name "os" or "io", thus disabling any possibility to actually access these commands, but I am not yet sure.
- a dialog box would be great, but harder to implement (GUI specific etc.). A simple message on screen would be easier (like with the print-command).
- a full implementation of Lua would mean including all standard lua-libraries, which really don't work well with any kind of message(-box) which pops up when encountering the dangerous commands. If this is at all possible (I am not sure) it would probably require some ugly hacks.

So these are the options from easy to maybe impossible (or at least the ones I can currently think of):
- do nothing
- add io+os libraries unconditionally
- add io+os libraries when some option in celestia.cfg is set
- add io+os libraries when an option in the settings menu is set(?)
- add io+os libraries when the script asks for it and the user allows it (via on-screen message or message box)
- add some substitute for the io+os libraries which first asks the user when a script tries to actually execute a senstitive command.

Harald

Harry wrote:- a full implementation of Lua would mean including all standard lua-libraries, which really don't work well with any kind of message(-box) which pops up when encountering the dangerous commands.

From the Lua 5.0 Reference Manual...

Currently, Lua has the following standard libraries:
• basic library;
• string manipulation;
• table manipulation;
• mathematical functions (sin, log, etc.);
• input and output;
• operating system facilities;
• debug facilities.

Thus, it would appear that the only "missing" libraries are I/O, OS and Debug (the last 3 listed). Why would these libraries work any different than all the other ones already included in Celestia? Or are you saying that Celestia would not know what Celx/Lua command is about to be executed?

Harry wrote:- I am not sure if the os and io commands can be activated seperately, as both are defined in the same lua library.

Not according to the Lua Manual: "All libraries are implemented through the official C API and are provided as separate C modules."

Harry wrote:- a dialog box would be great, but harder to implement (GUI specific etc.). A simple message on screen would be easier (like with the print-command).

Chris made the decision to have multiple UIs for multiple platforms, thus any change/addition that requires user-interaction will indeed be "not easy", since it needs to be coded for each UI. I'm not sure that messing up the script's current on-screen text for a prompt message is such a good idea.

don wrote:Or are you saying that Celestia would not know what Celx/Lua command is about to be executed?

That's what I meant. If these libraries are activated, they are simple there - the script can use them without any control by Celestia.

It may be possible to intercept the calls using Debug-Hooks, but this probably isn't secure, and you can't return to the main Celestia-loop while waiting for the allow/deny by the user (I am not even sure if all GUI-Toolkits would allow such behaviour).

Harry wrote:- I am not sure if the os and io commands can be activated seperately, as both are defined in the same lua library.

Not according to the Lua Manual: "All libraries are implemented through the official C API and are provided as separate C modules."

I too didn't know that at first, but read on (same section):

Lua Reference Manual wrote:To have access to these libraries, the C host program must first call the functions [...], luaopen_io (for the I/O and the Operating System libraries), [...].

So you can't activate only one of them. However it may be possible to "overwrite" one of the two names "io" and "os", and thus rendering one library inaccessible.

I'm not sure that messing up the script's current on-screen text for a prompt message is such a good idea.

It's not a good idea, but it increases the probability that it is implented at all - and adding a message-box could still be done at a later time if there is need.

Harald

Thank you for your clarifications Harald.

I personally, would be content with some settings in celestia.cfg.

I think the security problem here is not as severe as with scripts running over a network or inside a browser. Other than browsing with javascript, celestia does not automatically load scripts over a network, and it does not start scripts without knowledge of the user - so every possible problem is immediately trapped and will have serious consequences for the author.

maxim

Harry wrote:- add io+os libraries when some option in celestia.cfg is set

If any I'm for this method, with the default being false.

I havn't tried it yet but lua also has the ability to use dll's, I'm not sure if it needs the os library however. Perhaps there is already a security hole?

marc wrote:I havn't tried it yet but lua also has the ability to use dll's, I'm not sure if it needs the os library however. Perhaps there is already a security hole?

You are thinking of "loadlib", right? This would be a problem if it was actually there, but it isn't. It looks like you have to specifially add it while compiling lua (at least for Linux) and then activate it just like the io&os libraries. Blame the Lua-manual for not mentioning this

On an unrelated note: I don't think it makes sense to enable io and os seperately - if a script can write files, it probably can start a program (autorun etc.), and once it can execute programs writing isn't a problem anymore.

Harald

I wanted to use the CELEX Lua scripting interface to load a dll called LuaCLIPS. With this dll, I hope to include some AI into the scripts I make for Celestia.

However, when I call the loadlib() function in a CELEX script in Celestia, I get the following error:
Fatal Error:
Attempt to call global "loadlib' (a nil value)

I can run the exact same lua file in standalone Lua(5.02) and the luaCLIPS dll works fine.

So my question is:

How can I get the loadlib() function installed in the Lua engine in Celestia?

Maybe all these difficulties would go away if, instead of using an embedded scripting engine to do input/ouput and launch system commands, the Celestia API would be exposed to external programs (through COM on Windows for example, DBUS or DCOP on Linux). That would allow to use an external program to control a running instance of Celestia and lift restrictions on system interactions.

Otherwise I don't think implementing a dialog box callable from Lua is a problem. We just need to add a virtual class that will be derived by each toolkit implementation. Trapping 'insecure' Lua calls, without support for this in Lua itself seems much more difficult.

But let's not forget that in addition to security issues, io and os are disabled to keep the celx scripts platform independant, the moment you enable them scripts are garantied to become system dependant and probably very system dependant (ie only run on the author's computer). It would be more logical to add the needed system-level functionality to celx itself, this would then be implemented as system wrappers on each Celestia version with, if needed, proper security checks and warnings.

Christophe wrote:Maybe all these difficulties would go away if, instead of using an embedded scripting engine to do input/ouput and launch system commands, the Celestia API would be exposed to external programs (through COM on Windows for example, DBUS or DCOP on Linux). That would allow to use an external program to control a running instance of Celestia and lift restrictions on system interactions.
...
But let's not forget that in addition to security issues, io and os are disabled to keep the celx scripts platform independant, the moment you enable them scripts are garantied to become system dependant and probably very system dependant (ie only run on the author's computer). It would be more logical to add the needed system-level functionality to celx itself, this would then be implemented as system wrappers on each Celestia version with, if needed, proper security checks and warnings.

I believe the Lua io and os libraries are mostly system independent, as they are based on the standard C libraries. The loadlib function requires dynamic loading capabilities, but is implemented on the major platforms (provided Lua is built with the proper flag).

- Hank

I know the io and os libs are system independant, it's what you do with them which isn't.

io can probably done the proper way, but I'm pretty sure people will use absolute paths. And you obviously can't do much with os (execute being what people are after) without being OS specific.

As I said before, whatever it is people want to do with these libs, I'd rather have them submit feature requests for celx to be extended. And for example instead of writing:

they could write


That way we could do things like: provide configuration options to disable or warn the user for each type of action, or use the system defined web browser instead of whatever the script's author feels like using.

Christophe wrote:I know the io and os libs are system independant, it's what you do with them which isn't.

io can probably done the proper way, but I'm pretty sure people will use absolute paths. And you obviously can't do much with os (execute being what people are after) without being OS specific.

As I said before, whatever it is people want to do with these libs, I'd rather have them submit feature requests for celx to be extended. And for example instead of writing:

Code: Select all

os.execute('explorer.exe ' + some_url)

they could write

Code: Select all

celestia:web_browser(some_url)

That way we could do things like: provide configuration options to disable or warn the user for each type of action, or use the system defined web browser instead of whatever the script's author feels like using.

As a Mac user, I would certainly prefer that people developing Celestia scripts, extensions, and tools make them platform independent. I'm not sure that the approach of using external programs to control Celestia through COM on Windows or DCOP on Linux (OSA on Mac OS X?) would promote this. Adding generally useful functions to CELX would be helpful, but if they don't involve access to Celestia internals they could be better provided as Lua libraries. Requiring the submission of feature requests and waiting for a new version from the Celestia development team is much too constraining.

- Hank

Yes, having a separate project for Lua extensions with its own release cycle could be a good solution.

Christophe wrote:Yes, having a separate project for Lua extensions with its own release cycle could be a good solution.

What I was really trying to get at is that while generally useful Lua extensions should be included in the Celestia project, experimenters and add-on developers need to be able to make use of their own custom libraries as well.

- Hank

Experimenters can easily make a custom build of Celestia with os enabled.

Add-on writters shouldn't use libs unless they are supported on all platforms (at least the official Celestia distribution should encourage them to stay cross platform). Thatswhy I think maintaining our own extension set for use with Celestia seems like a reasonable compromise to me.

Christophe wrote:Experimenters can easily make a custom build of Celestia with os enabled.

I don't think experimenters should be required to build a custom version of Celestia in order to make extensions to Celestia using Lua. One of the main benefts of using Lua is that you can customize Celestia without having to make a custom build. (But just enabling CELX system access globally does not require a custom build, as there is already a configuration file entry to do this.)

Christophe wrote:Add-on writters shouldn't use libs unless they are supported on all platforms (at least the official Celestia distribution should encourage them to stay cross platform). Thatswhy I think maintaining our own extension set for use with Celestia seems like a reasonable compromise to me.

Add-on developers should certainly be encouraged to support all platforms, and a set of standard cross-platform libraries will facilitate this, but in some cases it may not be feasible for an add-on developer to provide cross-platform versions for a custom library. However, if the source for the custom library is distributed with the add-on, other users would be able to assist in developing versions for other platforms.

- Hank