httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Sch├╝tze <J...@DracoBlue.de>
Subject Re: [mod_wombat] Feature state
Date Wed, 02 May 2007 18:30:54 GMT
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


Mime
View raw message