httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch>
Subject mod_include and ap_expr
Date Sun, 15 May 2011 10:51:13 GMT

mod_include is still missing support for ap_expr. Trying to add that 
support raises some questions:

The mod_include expression parser tries hard to limit what can be done. 
For example, the subrequest operator -A can be switched of with a config 
option.  If mod_include was switched to ap_expr, this would open a lot of 
possibilities in the expression parser, like reading arbitrary files with 
the file() function, unrestricted file existance test, etc. I am not aware 
how mod_include is actually used in production, but if the *shtml files 
are untrusted, this could open a can of security problems. This is made 
even worse by the fact that modules can extend ap_expr. So, what kind of 
restrictions would be necessary for ap_expr in mod_include?

[ ] It would be enough to be able to switch back to the old, restricted
     expression parser.
[ ] All functions / operators should be classified into safe for
     mod_include or not safe for mod_include (with the classification being
[ ] One would need a detailed way to configure which functions /
     operators are allowed inside mod_include and which are not.

A different issue is that mod_include's parser is optimized for the 
expressions being parsed and then evaluated only once. ap_expr on the 
other hand is optimized for expressions being parsed once and then being 
evaluated often. Therefore it is possible that ap_expr would be slower in 
mod_include (but I haven't made any benchmark).

As I don't use mod_include, input from others would be very much 


View raw message