On Sunday 09 January 2011, William A. Rowe Jr. wrote: > On 1/8/2011 8:50 AM, Stefan Fritsch wrote: > > On Saturday 08 January 2011, [email protected] wrote: > >> Author: sf > >> Date: Sat Jan 8 14:29:12 2011 > >> New Revision: 1056713 > >> > >> URL: http://svn.apache.org/viewvc?rev=1056713&view=rev > >> Log: > >> Fix a bug in authz logic merging which caused > >> > >> section->op == AUTHZ_LOGIC_AND > >> auth_result == AUTHZ_DENIED_NO_USER > >> child_result == AUTHZ_GRANTED > >> > >> to return AUTHZ_GRANTED instead of AUTHZ_DENIED_NO_USER. > >> > >> While there, refactor the if blocks to make them a bit more > >> readable. > >> > >> Modified: > >> httpd/httpd/trunk/CHANGES > >> httpd/httpd/trunk/modules/aaa/mod_authz_core.c > > > > This was broken since r964156 / 2.3.8. > > > > Is there some agreed upon policy how to handle security issues > > that only affect alphas and/or betas? Do we need a CVE id? > > > > IMO: No for alphas, but maybe yes for betas? > > Well, if it was a concern, it wouldn't be committed until we were > prepared to release the replacement, which is why such patches are > first discussed at the [email protected] by exclusively project > members who are willing to review security-related changes. > > Since the ASF and others run alphas in production, these certainly > require appropriate handling, alpha beta or GA.
OK. > The only question is whether this represents an undisclosed and > unanticipated security flaw, or is a blatent and obvious bug in > behavior. If it's the former, it gets a CVE. If it's the later, > it just gets fixed. Because the code is in the auth section does > not automatically elevate it to a 'security vulnerability'. What > would elevate it is unexpected or inconsistent results that would > not be plainly observed by every administrator setting up this > configuration. I agree that this bug is not quite a security issue. Even though it causes somewhat unexpected behaviour, because it depends on the order of the require statements in the configuration file.
