Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Sun, 15 May 2011 12:51:13 +0200 (CEST)
From: Stefan Fritsch <sf@sfritsch.de>
To: dev@httpd.apache.org
Subject: mod_include and ap_expr
Message-ID: <alpine.DEB.1.10.1105151248130.8851@eru.sfritsch.de>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

Hi,

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
     hard-coded).
[ ] 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 
appreciated.

Cheers,
Stefan