On Fri, May 22, 2009 at 05:26:07PM +0100, Joe Orton wrote: > Attaching my original analysis for security@ which hopefully answers > that question ;)
attempt 2
I've now had a deeper look into this. I can't see a way to fix the problem without changing the semantics of the OPT_ bits used, as I mentioned briefly in my comment to Vincent. Status quo: a) OPT_INCLUDES is interpreted as "SSI is allowed with exec=" b) OPT_INCNOEXEC is interperted iff OPT_INCLUDES is also set as meaning "SSI is allowed but exec= is not" c) setting "AllowOverride Options=IncludesNoExec" results in both OPT_INCLUDES and OPT_INCNOEXEC being set in the ->override_opts bitmask, i.e. either or both options can be overridden in .htaccess files >From this leads the fact that an .htaccess file can set simply "Options Includes" in a context which inherits "AllowOverride Options=IncludesNoExec". I'm presuming nobody will argue that's a feature not a bug? If so, I think this is the set of constraints which need to be satisfied: 1) the result of a config merge with only "Options IncludesNoEXEC" specified must not allow use of exec= in SSI 2) if "AllowOverride Options=" is used without "Includes", notably, use of "AllowOverride Options=IncludesNoExec", use of "Options Includes" in an .htaccess file must be an error 3) if "AllowOverride Options=Includes" is set, use of both "Options Includes" and "Options IncludesNoExec" must succeed and enable SSI with or without exec= respectively 4) if permitted by AllowOverride, setting "Options Includes" in a context from which "Options IncludesNoExec" is inherited, then the result must be one where exec= is allowed. Attached is a patch which passes the tests I have so far - Vincent, can you easily re-run your tests used to produce that lovely matrix, with this applied? Regards, Joe