You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by David Reid <da...@jetnet.co.uk> on 2006/02/11 01:58:43 UTC
Re: Change in how to configure authorization
Joshua Slive wrote:
> On 1/26/06, Ian Holsman <li...@holsman.net> wrote:
>
>>Hi Joshua:
>>
>>httpd.conf.in has the new structure
>>httpd-std.conf (the one I was looking at) didn't ;(
>
>
> Hmmm... httpd-std.conf doesn't exist in trunk.
Just ran into this and couldn't quite believe what I was seeing.
I have a similar config on a server and basically unless you're very
careful you end up shutting people out! This change in auth seems to
make no sense to me.
It's adding a lot of complexity to config files. Do we really need to
make this change? Really?
At the very least can someone please document how config files need to
be changed... And no, I don't think having it in a sample config file is
enough.
david
Re: Change in how to configure authorization
Posted by David Reid <da...@jetnet.co.uk>.
Joshua Slive wrote:
> On 2/10/06, David Reid <da...@jetnet.co.uk> wrote:
>
>>Joshua Slive wrote:
>>
>>>On 1/26/06, Ian Holsman <li...@holsman.net> wrote:
>>>
>>>
>>>>Hi Joshua:
>>>>
>>>>httpd.conf.in has the new structure
>>>>httpd-std.conf (the one I was looking at) didn't ;(
>>>
>>>
>>>Hmmm... httpd-std.conf doesn't exist in trunk.
>>
>>Just ran into this and couldn't quite believe what I was seeing.
>>
>>I have a similar config on a server and basically unless you're very
>>careful you end up shutting people out! This change in auth seems to
>>make no sense to me.
>>
>>It's adding a lot of complexity to config files. Do we really need to
>>make this change? Really?
>>
>>At the very least can someone please document how config files need to
>>be changed... And no, I don't think having it in a sample config file is
>>enough.
>
>
> No argument on any of that. But the idea is that if you include
> mod_access_compat, it should be config-file-compatible with older
> versions.
> If that isn't true, you should provide details.
Well, I had the warnings about the commands being deprecated, but the
site didn't work and kept giving me 401 errors.
When I changed to the "new" commands it worked. *shrug*
Also, LimitExcept doesn't seem to be working at all. Also mod_authn_dbd
still isn't working reliably for me. Works for a short while then stops,
starts and stops again at unpredictable intervals...
david
Re: Change in how to configure authorization
Posted by Joshua Slive <jo...@slive.ca>.
On 2/10/06, David Reid <da...@jetnet.co.uk> wrote:
> Joshua Slive wrote:
> > On 1/26/06, Ian Holsman <li...@holsman.net> wrote:
> >
> >>Hi Joshua:
> >>
> >>httpd.conf.in has the new structure
> >>httpd-std.conf (the one I was looking at) didn't ;(
> >
> >
> > Hmmm... httpd-std.conf doesn't exist in trunk.
>
> Just ran into this and couldn't quite believe what I was seeing.
>
> I have a similar config on a server and basically unless you're very
> careful you end up shutting people out! This change in auth seems to
> make no sense to me.
>
> It's adding a lot of complexity to config files. Do we really need to
> make this change? Really?
>
> At the very least can someone please document how config files need to
> be changed... And no, I don't think having it in a sample config file is
> enough.
No argument on any of that. But the idea is that if you include
mod_access_compat, it should be config-file-compatible with older
versions.
If that isn't true, you should provide details.
Joshua.
Re: Change in how to configure authorization
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 2/17/2006 at 10:38:17 am, in message
<20...@redhat.com>,
jorton@redhat.com wrote:
> On Tue, Feb 14, 2006 at 11:11:22AM -0700, Brad Nicholes wrote:
>> >>> On 2/14/2006 at 3:50 am, in message
>> <20...@redhat.com>,
>> jorton@redhat.com wrote:
>> > On Mon, Feb 13, 2006 at 03:42:27PM -0700, Brad Nicholes wrote:
>> >>
>> >> The other problem that I see in the configuration is that the
>> <Location
>> >> /authany> defines an authtype and authname but no authentication
>> >> provider. This means that the authentication provider will
default
>> to
>> >> 'file'. But since there hasn't been a password file specified
>> either,
>> >> the result is an AUTH_GENERAL_ERROR. This scenario would occur
>> with
>> >> either 2.2 or trunk.
>> >
>> > mod_authany is supposed to key off the AuthName configured for the
>> > location - if it's equal to "authname" then it kicks in and does
the
>>
>> > dummy authz hack. No argument that this is a weird hack, but this
>> > worked in 2.2 and earlier, is there any way it can do something
>> similar
>> > without requiring a config file change?
>> >
>> > joe
>>
>> This is where I am a little confused. The AUTH_GENERAL_ERROR is
coming
>> from the authn side not authz and nothing has really changed in
authn
>> between 2.2 and 2.3. So I don't understand how it worked in 2.2.
>> Looking at the code again, I think you are still going to need the
>> authany_handler() to handle the authentication. If mod_auth_basic
tries
>> to handle the authentication, then it will attempt to default to
'file'
>> and fail as I mentioned before. In fact, everything that was
working
>> before should continue to work correctly. There is nothing to
prevent a
>> module from grabbing the same check_user_id and auth_checker hooks
and
>> handling them.
>
> Sorry, everything I wrote above is wrong, not sure what I was smoking
> that day...
>
> mod_authany with 2.2 and earlier was checking for the configuration
> "Require user any-user" and then allowing authz if *any* basic auth
> credentials had been sent in the request. With the trunk code, since
> the check_user_id hook can no longer get to the requirements array
> (ap_requires() has gone), it can't do this any more. This is the
> problem I was trying to work around and failing...
>
> jo
So that's all OK and you can implement the authorization provider to
check that, but from what I can see you still need to register for the
authentication hook and hook it first as was being done previously. If
you don't and you allow mod_auth_basic to handle the authentication, it
will default to the 'file' provider which will fail with a
AUTH_GENERAL_ERROR. My point being that in your update to the 2.3 code,
you went too far by taking out the ap_hook_check_user_id() hook. As far
as the authorization provider goes, the only reason for looping through
the ap_requires() elts was because all of the 'require' methods where
lumped together which required you to sift through them all to determine
if the one you were interested in is there. With the provider based
implementation this is no longer necessary hence ap_requires() is no
longer necessary. If you 'require user' then the 'user' provider is
what gets called. So in the mod_authany case, you can create an
'any-user' provider and if it gets called, then it returns GRANTED.
Which is exactly what 'valid-user' is doing so why not just use
'valid-user'? Bottom line is that mod_auth_any just got smaller. All
you really need is the authentication hook to intercept the
check_user_id call. Everything else can just be handled by the existing
stuff.
I would go in and try to rework this myself but I can't get the
framework to work at all on any version of Apache. When I run the
Makefile.PL everything builds and starts just fine up until the
framework checks to see if Apache is alive. At that point it just hangs
there and finally times out assuming that Apache never completely
started. I can hit the httpd server from a browser and all looks good
but I don't know what the script is waiting for.
Brad
Re: Change in how to configure authorization
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Feb 14, 2006 at 11:11:22AM -0700, Brad Nicholes wrote:
> >>> On 2/14/2006 at 3:50 am, in message
> <20...@redhat.com>,
> jorton@redhat.com wrote:
> > On Mon, Feb 13, 2006 at 03:42:27PM -0700, Brad Nicholes wrote:
> >>
> >> The other problem that I see in the configuration is that the
> <Location
> >> /authany> defines an authtype and authname but no authentication
> >> provider. This means that the authentication provider will default
> to
> >> 'file'. But since there hasn't been a password file specified
> either,
> >> the result is an AUTH_GENERAL_ERROR. This scenario would occur
> with
> >> either 2.2 or trunk.
> >
> > mod_authany is supposed to key off the AuthName configured for the
> > location - if it's equal to "authname" then it kicks in and does the
>
> > dummy authz hack. No argument that this is a weird hack, but this
> > worked in 2.2 and earlier, is there any way it can do something
> similar
> > without requiring a config file change?
> >
> > joe
>
> This is where I am a little confused. The AUTH_GENERAL_ERROR is coming
> from the authn side not authz and nothing has really changed in authn
> between 2.2 and 2.3. So I don't understand how it worked in 2.2.
> Looking at the code again, I think you are still going to need the
> authany_handler() to handle the authentication. If mod_auth_basic tries
> to handle the authentication, then it will attempt to default to 'file'
> and fail as I mentioned before. In fact, everything that was working
> before should continue to work correctly. There is nothing to prevent a
> module from grabbing the same check_user_id and auth_checker hooks and
> handling them.
Sorry, everything I wrote above is wrong, not sure what I was smoking
that day...
mod_authany with 2.2 and earlier was checking for the configuration
"Require user any-user" and then allowing authz if *any* basic auth
credentials had been sent in the request. With the trunk code, since
the check_user_id hook can no longer get to the requirements array
(ap_requires() has gone), it can't do this any more. This is the
problem I was trying to work around and failing...
joe
Re: Change in how to configure authorization
Posted by Brad Nicholes <bn...@novell.com>.
>>> On 2/14/2006 at 3:50 am, in message
<20...@redhat.com>,
jorton@redhat.com wrote:
> On Mon, Feb 13, 2006 at 03:42:27PM -0700, Brad Nicholes wrote:
>>
>> The other problem that I see in the configuration is that the
<Location
>> /authany> defines an authtype and authname but no authentication
>> provider. This means that the authentication provider will default
to
>> 'file'. But since there hasn't been a password file specified
either,
>> the result is an AUTH_GENERAL_ERROR. This scenario would occur
with
>> either 2.2 or trunk.
>
> mod_authany is supposed to key off the AuthName configured for the
> location - if it's equal to "authname" then it kicks in and does the
> dummy authz hack. No argument that this is a weird hack, but this
> worked in 2.2 and earlier, is there any way it can do something
similar
> without requiring a config file change?
>
> joe
This is where I am a little confused. The AUTH_GENERAL_ERROR is coming
from the authn side not authz and nothing has really changed in authn
between 2.2 and 2.3. So I don't understand how it worked in 2.2.
Looking at the code again, I think you are still going to need the
authany_handler() to handle the authentication. If mod_auth_basic tries
to handle the authentication, then it will attempt to default to 'file'
and fail as I mentioned before. In fact, everything that was working
before should continue to work correctly. There is nothing to prevent a
module from grabbing the same check_user_id and auth_checker hooks and
handling them.
Brad
Re: Change in how to configure authorization
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Feb 13, 2006 at 03:42:27PM -0700, Brad Nicholes wrote:
> >>> On 2/13/2006 at 8:39:41 am, in message
> <20...@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
> >
> > joe
>
> The other problem that I see in the configuration is that the <Location
> /authany> defines an authtype and authname but no authentication
> provider. This means that the authentication provider will default to
> 'file'. But since there hasn't been a password file specified either,
> the result is an AUTH_GENERAL_ERROR. This scenario would occur with
> either 2.2 or trunk.
mod_authany is supposed to key off the AuthName configured for the
location - if it's equal to "authname" then it kicks in and does the
dummy authz hack. No argument that this is a weird hack, but this
worked in 2.2 and earlier, is there any way it can do something similar
without requiring a config file change?
joe
Re: Change in how to configure authorization
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 2/13/2006 at 8:39:41 am, in message
<20...@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
>
> joe
The other problem that I see in the configuration is that the <Location
/authany> defines an authtype and authname but no authentication
provider. This means that the authentication provider will default to
'file'. But since there hasn't been a password file specified either,
the result is an AUTH_GENERAL_ERROR. This scenario would occur with
either 2.2 or trunk.
Brad
Re: Change in how to configure authorization
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 2/13/2006 at 8:39:41 am, in message
<20...@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
Re: Change in how to configure authorization
Posted by Joe Orton <jo...@redhat.com>.
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
joe
Re: Change in how to configure authorization
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 2/10/2006 at 5:58:43 pm, in message
<43...@jetnet.co.uk>,
david@jetnet.co.uk wrote:
> Joshua Slive wrote:
>> On 1/26/06, Ian Holsman <li...@holsman.net> wrote:
>>
>>>Hi Joshua:
>>>
>>>httpd.conf.in has the new structure
>>>httpd-std.conf (the one I was looking at) didn't ;(
>>
>>
>> Hmmm... httpd-std.conf doesn't exist in trunk.
>
> Just ran into this and couldn't quite believe what I was seeing.
>
> I have a similar config on a server and basically unless you're very
> careful you end up shutting people out! This change in auth seems to
> make no sense to me.
>
> It's adding a lot of complexity to config files. Do we really need
to
> make this change? Really?
>
> At the very least can someone please document how config files need
to
> be changed... And no, I don't think having it in a sample config file
is
> enough.
>
> davi
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.
Brad