Thanks for the fast comments to Paul and Brian!
> If by Base Dir you mean a base path for relative paths in configuration
With base dir I meant protection, so that the script can't access the
path beyond it. In some cases it is bad, if a webscript can read the
passwordfile of the server or on a shared host write into the directory
of another user.
> Base Dir & Safemode, Do we got something like this(e.g. like in php),
yet?
> -0.9; This is being removed from PHP in 6.0, IIRC... It just has too
> many problems, when you start adding 3rd party extensions/modules, which
> do their own IO. They started to solve more of this in 5.x, using IO
> streams everywhere, but for some libraries it still was extremely
> difficult, and there are still many security issues from this
> 'mis-feature' IMO.
Safemode: I talked with some hosters/webmasters which host projects of
mine, and some of them said that this is a required feature.
Even though some of them wasn't able to tell me what they liked most of
this "feature". With most scripts in php its much better to turn it off,
if you want to be sure the script works as expected.
Just appended it to the feature state-question to see and clear up the
conversations with those hosters about adding lua as scirpting language,
too.
Abou the BaseDir-Restriction:
I think that it is not task of mod_wombat to secure that all extensions
are "secure" in that way. But it should be possible to have at least for
the default (without extensions) implementation of mod_wombat a
protection (possible to disable/enable of course). Am not sure if lua
has such feature already built in (official manual
http://www.lua.org/manual/5.1/manual.html doesn't show something about
this). But for hosters, where multiple users have accounts and scripts
it is really needed to protect a users script from access of other users.
>I think via the httpd.conf you should be able to:
> - Control Loading of Lua Code in external files
> - Control Loading of modules/dll/so.
Yes.
>complex and simple post/get vars?
I mean the access to multiple passed arguments for one var. For example
if you got a multiselect in html you have to use a invalid xhtml
variable name. While testing mod_wombat 3 month ago, I already saw
r:parseargs(). You see that the double value for Adasda gets lost in the
simple view, but not in the complex one - that is good!!
Example (complex):
[asdas] => Table {
{
[1] => sss
}
[Adasda] => Table {
{
[1] => asdas
[2] => weqw
}
[asdasdasdasda] => Table {
{
[1] => ASdasdas
}
Example (simple)
[asdas] => sss
[Adasda] => asdas
[asdasdasdasda] => ASdasdas
(taken from my luainfo for mod_wombat,
http://dracoblue.net/Downloads/luainfo.lua.html )
It should be possible to disable loading such files from the scripts
directory, because it would (/can) allow execution of functions,
which aren't exported by the default lua-libraries.
*Dis(/En)able loading of .dll/.so*
Nothing is built into mod_wombat for this and I don't foresee adding
it anytime soon as right now loading lua's bas elibraries requires
loading shared libraries. We could try to set up the lua vm to do some
magic to only allow loading certain ones, but I fear that is a
slippery slope. The better approach is probably to limit the load
paths in Lua (which it does by default, really well), rather than
trying to do something in wombat specifically.
Not quite sure, if thats already the fact in default lua, but you got in
lua a variable called package.cpath to get the path for its
require-function. So it would be very easy to append a string while
scriptexecution and have loading libraries on the fly - which can be a
security issue.
>> <% %>, <?lua ?>
>Brian: I have no plans to implement a template system as part of
mod_wombat. I know Kepler has one, and it should work fine with mod_wombat.
>Paul:I think we should be careful about inventing another inline
templating/scripting language.
- Jan
--
http://dracoblue.net
