[mod_wombat] Feature state

[Jan Schütze <Ja...@DracoBlue.de>]

Hello,

just wanted to get an overview about the state of the mod_wombat module.

*Base Dir & Safemode*
Do we got something like this(e.g. like in php), yet?

*complex & simple post/get vars*
Already tested it on the old svn, so I expect it to work still.

*Dis(/En)able loading of .dll/.so*
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.

*Inline Error Display*
Last time while talking with Brian , we noticed that its really easy to 
write a "error handler" in mod_wombat. But one thing I was only able to 
see in log are the syntax parse errors.
Is there something like an inline-display implemented, yet?

*short tags*
Am not sure if we talked about this yet, but do we have <?lua ?> or <% 
%> tags?
Though the module follows a handler-style (not executing whole script, 
just calling a handler function), this feature may not be implemented, 
but since its common on most web-scripting languages, I ask about its state.

- Jan

-- 

 Kind regards,

  Jan (DracoBlue)

 http://dracoblue.net/

Re: [mod_wombat] Feature state

[Jan Schütze <Ja...@DracoBlue.de>]

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

Re: [mod_wombat] Feature state

[Brian McCallister <br...@apache.org>]

On May 1, 2007, at 1:49 AM, Jan Schütze wrote:

> *Base Dir & Safemode*
> Do we got something like this(e.g. like in php), yet?

If by Base Dir you mean a base path for relative paths in  
configuration, it's done. If you man something else, I don't know  
what you mean.

Safe mode: only what is built into Lua

> *complex & simple post/get vars*
> Already tested it on the old svn, so I expect it to work still.

Umh. What are complex and simple post/get vars? If you mean parsing  
of form encoded post data and CGI's standard uri params, that is  
still there via libapreq2. I epxect libapreq2 to become optional in  
mod_wombat at some unspecified date in the future (prior to a stable  
release) in which case you could use Kepler's parsing magic as an  
alternative.

> *Dis(/En)able loading of .dll/.so*
> 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.

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.


> *Inline Error Display*
> Last time while talking with Brian , we noticed that its really  
> easy to write a "error handler" in mod_wombat. But one thing I was  
> only able to see in log are the syntax parse errors.
> Is there something like an inline-display implemented, yet?

This has not yet been implemented, though it is a planned feature (in  
my book).

> *short tags*
> Am not sure if we talked about this yet, but do we have <?lua ?> or  
> <% %> tags?
> Though the module follows a handler-style (not executing whole  
> script, just calling a handler function), this feature may not be  
> implemented, but since its common on most web-scripting languages,  
> I ask about its state.

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.

-Brian

Re: [mod_wombat] Feature state

[Paul Querna <ch...@force-elite.com>]

Jan Schütze wrote:
> Hello,
> 
> just wanted to get an overview about the state of the mod_wombat module.
> 
> *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.


> *Dis(/En)able loading of .dll/.so*
> 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.

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.


> *Inline Error Display*
> Last time while talking with Brian , we noticed that its really easy to
> write a "error handler" in mod_wombat. But one thing I was only able to
> see in log are the syntax parse errors.
> Is there something like an inline-display implemented, yet?

+0.5, I would ask that it is disabled by default however.

> *short tags*
> Am not sure if we talked about this yet, but do we have <?lua ?> or <%
> %> tags?
> Though the module follows a handler-style (not executing whole script,
> just calling a handler function), this feature may not be implemented,
> but since its common on most web-scripting languages, I ask about its
> state.

I think we should be careful about inventing another inline
templating/scripting language.

Thanks,

-Paul