Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-Id: <43F08DAD.6720.00AC.0@novell.com>
Date: Mon, 13 Feb 2006 13:49:34 -0700
From: "Brad Nicholes" <BNICHOLES@novell.com>
To: <dev@httpd.apache.org>,<jorton@redhat.com>
Subject: Re: Change in how to configure authorization
References: <43D98870.3080004@holsman.net>
  <e498c1660601270634h14623f82vc292de5152f6b36@mail.gmail.com>
  <43ED36C3.4070807@jetnet.co.uk>  <43F041FE.6720.00AC.0@novell.com>
 <20060213153940.GA3212@redhat.com>
In-Reply-To: <20060213153940.GA3212@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

>>> On 2/13/2006 at 8:39:41 am, in message
<20060213153940.GA3212@redhat.com>,
jorton@redhat.com wrote:
> On Mon, Feb 13, 2006 at 08:26:39AM -0700, Brad Nicholes wrote:
>> Yes, we do need to make this change.  With the provider based 
>> rearchitecting of authentication in httpd 2.2, this left
authorization 
>> in an unpredictable state especially when using multiple
authorization 
>> types.  You were never quite sure which one was going to happen
first 
>> and had no way to order them or control them.  With that, there was

>> also a growing demand to be able to apply AND/OR logic to the way in

>> which authorization is applied.  So basically this change brings 
>> authorization up to the same level of power and flexibility that 
>> currently exists in httpd 2.2 for authentication.  Hence being new 
>> functionality, there are bound to be bugs that need to be fixed, 
>> especially with backwards compatibility.  So let's get the bugs 
>> identified and fixed.
> 
> Could you have a look at making the test suite pass again, to that
end?
> 
> I tried to port mod_authany (c-modules/authany/mod_authany.c) to the

> trunk authz API, but to no avail.  The tests which fail are:
> 
> t/http11/basicauth..........# Failed test 2 in t/http11/basicauth.t
at 
> line 24
> FAILED test 2
> 	Failed 1/3 tests, 66.67% okay
> t/security/CVE-2004-0811....# Failed test 1 in 
> t/security/CVE-2004-0811.t at line 14
> # Failed test 2 in t/security/CVE-2004-0811.t at line 14 fail #2
> # Failed test 3 in t/security/CVE-2004-0811.t at line 14 fail #3
> # Failed test 4 in t/security/CVE-2004-0811.t at line 14 fail #4
> FAILED tests 1-4
> 
> jo

The problem that I see with mod_anyuser is that it is trying to
re-register the 'user' authorization provider.  All of the authorization
types must be unique.  So in this case, the provider should probably be
called 'any-user' or something like that.  Then, according to the code,
the whole thing looks a lot like 'valid-user'.  Is there a reason why
the test configuration doesn't just use 'valid-user'?

Brad