You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brad Nicholes <bn...@novell.com> on 2006/01/07 05:34:57 UTC
Re: Merging branch authz-dev - Authorization and Access
Control 2.3 vs. 2.2
>>> On 1/6/2006 at 5:45 pm, in message
<e4...@mail.gmail.com>,
joshua@slive.ca
wrote:
> On 1/6/06, Brad Nicholes <BN...@novell.com> wrote:
>> The Authz refactoring in /branch/authz-dev is basically done and
I am
>> about ready to merge the branch back into trunk. Before I do that,
I
>> would like to describe the impact that the Authz change will have
going
>> forward, as well as the benefits. All of this looks like a
massive
>> change to authorization and access control, which granted it is.
>> However, I have tried as much as possible to minimize the impact to
>> existing configuration files.
>
> These are my comments based on a very superficial look.
>
> First, I think the overall idea is great and much clearer than what
we have
> now.
>
> But I do think the necessary config changes are rather massive,
> touching a large percentage of .htaccess files and <Directory>
> sections, not to mention third-party auth modules. I would think
> that, by sacrificing some purity, it should be possible to support
> many of these configs and modules. For example, shouldn't it be
> possible to create a mod_access_deprecated that impliments
> Order/Allow/Deny? Obviously satisfy would add a lot of
complication,
> but I bet 90%+ of existing configs would work fine if the default
> Satisfy All was made to work, so the Satisfy directive itself
probably
> wouldn't need to be included.
>
Well possibly but the problem is that Order/Allow/Deny implements
access control independently from the rest of the authorization. The
point is to try to bring them all together and eliminate the confusion.
It may be a bit of a pain to upgrade, but I think in the end it will all
make a lot more sense. As for the third party auth modules, they are
going to have to make the split anyway in order to fit the current
authn/authz architecture in 2.2. It's not a major leap for them to
modify the resulting authz module to fit the new authz model in 2.3.
> I guess an alternative would be a fancy python script to convert
> config/.htaccess files.
>
IMO, this would probably be the better solution.
> As far as the new config directives, a couple questions:
>
> 1. Why split "Allow from" into "Require ip" and "Require host".
There
> is no ambiguity between a hostname and an IP address, as far as I
> know, so it would seem more straightforward to have only "Require
> host" and let httpd figure out whether it is an IP address or
> hostname.
>
I believe that this could probably be done. Basically "Allow from"
was split into the 'IP', 'Host', etc. providers because that is how it
was represented in the source code and it just naturally fell out that
way.
> 2. "Require all granted" and "Require all denied" seem a little
obtuse
> to me. As evidence, I note that you chose to document them by
> refering to the old config, rather than explaining what they do ;-)
> Perhaps simply "Require host *" and "Reject host *" or "Require host
> all"/"Reject host all" would be clearer alternatives. (In the
> process, getting rid of another Require option and getting us closer
> to a more familiar config.)
>
Honestly, I struggled with this naming myself but really couldn't
come up with anything better that would accurately represent "Allow from
all" or "Deny from all" and still fit the authz provider model. I'm not
sure that "Require host all"/"Reject host all" quite fits it either
because we aren't always talking about a host.
> 3. The <RequireAll> and <RequireOne> names seem a touch confusing
> given that they apply to both require and reject directives.
Perhaps
> back to the good old <SatisfyAll/One> or <MatchAll/One>?
>
Again, I struggled with this naming as well. I'm not opposed to
changing it to <SatisfyAll>/<SatisfyOne>. It works for me. :)
> 4. It isn't made clear anywhere whether RequireAll or RequireOne is
the
> default.
Yeah it probably needs to be stated somewhere, however the default
is <RequireOne> basically because that is how it works today if you use
multiple Require directives. I guess I kind of expected that to be
obvious.
>
> Joshua.
Thanks for the feedback,
Brad
Re: Merging branch authz-dev - Authorization and Access
Control 2.3vs. 2.2
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 1/13/2006 at 8:19:39 am, in message
<e4...@mail.gmail.com>,
joshua@slive.ca
wrote:
> I would consider moving this compat code into mod_access_compat or
> something of the like so that it would be easy for people to select
> whether they want the clean new system or a mix of the new and old
> system. Since this change will not come until at least 2.4, I think
> it is acceptable to have module name changes (as we did from 2.0 to
> 2.2).
>
> Joshua.
I'm OK with that. I will rework the patch into a mod_access_compat
module.
Brad
Re: Merging branch authz-dev - Authorization and Access Control 2.3vs. 2.2
Posted by Joshua Slive <jo...@slive.ca>.
On 1/12/06, Brad Nicholes <bn...@novell.com> wrote:
> OK, try this on for size. Since Order,Allow,Deny are all hooked at
> the access_checker stage, we should be able to add these directives back
> in and allow them to function normally. The real problem is 'Satisfy'
> because it had its fingers into the middle of
> ap_process_request_internal(). So to get around this problem, I added
> the directive back into mod_authz_host (along with Order,Allow,Deny) and
> let it do it thing also. 'Satisfy All' is the default (as it was
> before) meaning that if the access_checker fails or the authz_checker
> fails, then the entire request fails. But if 'Satisfy Any' is specified
> then if the access_checker fails, it makes a note of that fact in the
> request_rec->notes and defers to the authz_checker. If the
> authz_checker fails, obviously the request fails. But if the request
> makes it all the way to the mod_authz_default handler, this handler
> checks the note and determines whether or not to authorize or reject the
> request based on what the current state of both access control and
> authz.
>
> So what this means is that Order,Allow,Deny,Satisfy are back and
> *should* function as before along side of the new authz model. This
> should resolve the backward compatibility issue with the following
> caveat. Both mod_authn_default and mod_authz_default modules must be
> loaded. These module implement the catch-all handlers that allow things
> to work if no authn or authz is implemented for a <Directory> or
> <Location>. Otherwise access is automatically denied. What I would like
> to see is the above *should* confirmed to be a *do*. In other words, I
> am looking for some help testing this. Any takers? So far my testing
> shows that things are good.
The idea seems right to me. I'll try to find time to do some testing,
but I'm pretty backed-up at the moment.
I would consider moving this compat code into mod_access_compat or
something of the like so that it would be easy for people to select
whether they want the clean new system or a mix of the new and old
system. Since this change will not come until at least 2.4, I think
it is acceptable to have module name changes (as we did from 2.0 to
2.2).
Joshua.
Re: Merging branch authz-dev - Authorization and Access
Control 2.3vs. 2.2
Posted by Brad Nicholes <bn...@novell.com>.
OK, try this on for size. Since Order,Allow,Deny are all hooked at
the access_checker stage, we should be able to add these directives back
in and allow them to function normally. The real problem is 'Satisfy'
because it had its fingers into the middle of
ap_process_request_internal(). So to get around this problem, I added
the directive back into mod_authz_host (along with Order,Allow,Deny) and
let it do it thing also. 'Satisfy All' is the default (as it was
before) meaning that if the access_checker fails or the authz_checker
fails, then the entire request fails. But if 'Satisfy Any' is specified
then if the access_checker fails, it makes a note of that fact in the
request_rec->notes and defers to the authz_checker. If the
authz_checker fails, obviously the request fails. But if the request
makes it all the way to the mod_authz_default handler, this handler
checks the note and determines whether or not to authorize or reject the
request based on what the current state of both access control and
authz.
So what this means is that Order,Allow,Deny,Satisfy are back and
*should* function as before along side of the new authz model. This
should resolve the backward compatibility issue with the following
caveat. Both mod_authn_default and mod_authz_default modules must be
loaded. These module implement the catch-all handlers that allow things
to work if no authn or authz is implemented for a <Directory> or
<Location>. Otherwise access is automatically denied. What I would like
to see is the above *should* confirmed to be a *do*. In other words, I
am looking for some help testing this. Any takers? So far my testing
shows that things are good.
I'll commit this patch to trunk of nobody sees any glaring issues.
Brad
Index: modules/aaa/mod_authz_host.c
===================================================================
--- modules/aaa/mod_authz_host.c (revision 368081)
+++ modules/aaa/mod_authz_host.c (working copy)
@@ -44,22 +44,175 @@
#include <netinet/in.h>
#endif
+enum allowdeny_type {
+ T_ENV,
+ T_ALL,
+ T_IP,
+ T_HOST,
+ T_FAIL
+};
+
typedef struct {
- int dummy; /* just here to stop compiler warnings for now. */
+ apr_int64_t limited;
+ union {
+ char *from;
+ apr_ipsubnet_t *ip;
+ } x;
+ enum allowdeny_type type;
+} allowdeny;
+
+/* things in the 'order' array */
+#define DENY_THEN_ALLOW 0
+#define ALLOW_THEN_DENY 1
+#define MUTUAL_FAILURE 2
+
+/** all of the requirements must be met */
+#define SATISFY_ALL 0
+/** any of the requirements must be met */
+#define SATISFY_ANY 1
+/** There are no applicable satisfy lines */
+#define SATISFY_NOSPEC 2
+
+
+typedef struct {
+ int order[METHODS];
+ apr_array_header_t *allows;
+ apr_array_header_t *denys;
+ int *satisfy; /* for every method one */
} authz_host_dir_conf;
module AP_MODULE_DECLARE_DATA authz_host_module;
static void *create_authz_host_dir_config(apr_pool_t *p, char *dummy)
{
+ int i;
authz_host_dir_conf *conf =
(authz_host_dir_conf *)apr_pcalloc(p,
sizeof(authz_host_dir_conf));
+ for (i = 0; i < METHODS; ++i) {
+ conf->order[i] = DENY_THEN_ALLOW;
+ }
+ conf->allows = apr_array_make(p, 1, sizeof(allowdeny));
+ conf->denys = apr_array_make(p, 1, sizeof(allowdeny));
+ conf->satisfy = apr_palloc(p, sizeof(*conf->satisfy) * METHODS);
+ for (i = 0; i < METHODS; ++i) {
+ conf->satisfy[i] = SATISFY_NOSPEC;
+ }
+
return (void *)conf;
}
+static const char *order(cmd_parms *cmd, void *dv, const char *arg)
+{
+ authz_host_dir_conf *d = (authz_host_dir_conf *) dv;
+ int i, o;
+
+ if (!strcasecmp(arg, "allow,deny"))
+ o = ALLOW_THEN_DENY;
+ else if (!strcasecmp(arg, "deny,allow"))
+ o = DENY_THEN_ALLOW;
+ else if (!strcasecmp(arg, "mutual-failure"))
+ o = MUTUAL_FAILURE;
+ else
+ return "unknown order";
+
+ for (i = 0; i < METHODS; ++i)
+ if (cmd->limited & (AP_METHOD_BIT << i))
+ d->order[i] = o;
+
+ return NULL;
+}
+
+static const char *satisfy(cmd_parms *cmd, void *dv, const char *arg)
+{
+ authz_host_dir_conf *d = (authz_host_dir_conf *) dv;
+ int satisfy = SATISFY_NOSPEC;
+ int i;
+
+ if (!strcasecmp(arg, "all")) {
+ satisfy = SATISFY_ALL;
+ }
+ else if (!strcasecmp(arg, "any")) {
+ satisfy = SATISFY_ANY;
+ }
+ else {
+ return "Satisfy either 'any' or 'all'.";
+ }
+
+ for (i = 0; i < METHODS; ++i) {
+ if (cmd->limited & (AP_METHOD_BIT << i)) {
+ d->satisfy[i] = satisfy;
+ }
+ }
+
+ return NULL;
+}
+
+static const char *allow_cmd(cmd_parms *cmd, void *dv, const char
*from,
+ const char *where_c)
+{
+ authz_host_dir_conf *d = (authz_host_dir_conf *) dv;
+ allowdeny *a;
+ char *where = apr_pstrdup(cmd->pool, where_c);
+ char *s;
+ char msgbuf[120];
+ apr_status_t rv;
+
+ if (strcasecmp(from, "from"))
+ return "allow and deny must be followed by 'from'";
+
+ a = (allowdeny *) apr_array_push(cmd->info ? d->allows :
d->denys);
+ a->x.from = where;
+ a->limited = cmd->limited;
+
+ if (!strncasecmp(where, "env=", 4)) {
+ a->type = T_ENV;
+ a->x.from += 4;
+
+ }
+ else if (!strcasecmp(where, "all")) {
+ a->type = T_ALL;
+ }
+ else if ((s = ap_strchr(where, '/'))) {
+ *s++ = '\0';
+ rv = apr_ipsubnet_create(&a->x.ip, where, s, cmd->pool);
+ if(APR_STATUS_IS_EINVAL(rv)) {
+ /* looked nothing like an IP address */
+ return "An IP address was expected";
+ }
+ else if (rv != APR_SUCCESS) {
+ apr_strerror(rv, msgbuf, sizeof msgbuf);
+ return apr_pstrdup(cmd->pool, msgbuf);
+ }
+ a->type = T_IP;
+ }
+ else if (!APR_STATUS_IS_EINVAL(rv = apr_ipsubnet_create(&a->x.ip,
where,
+ NULL,
cmd->pool))) {
+ if (rv != APR_SUCCESS) {
+ apr_strerror(rv, msgbuf, sizeof msgbuf);
+ return apr_pstrdup(cmd->pool, msgbuf);
+ }
+ a->type = T_IP;
+ }
+ else { /* no slash, didn't look like an IP address => must be a
host */
+ a->type = T_HOST;
+ }
+
+ return NULL;
+}
+
+static char its_an_allow;
+
static const command_rec authz_host_cmds[] =
{
+ AP_INIT_TAKE1("order", order, NULL, OR_LIMIT,
+ "'allow,deny', 'deny,allow', or 'mutual-failure'"),
+ AP_INIT_ITERATE2("allow", allow_cmd, &its_an_allow, OR_LIMIT,
+ "'from' followed by hostnames or IP-address
wildcards"),
+ AP_INIT_ITERATE2("deny", allow_cmd, NULL, OR_LIMIT,
+ "'from' followed by hostnames or IP-address
wildcards"),
+ AP_INIT_TAKE1("Satisfy", satisfy, NULL, OR_AUTHCFG,
+ "access policy if both allow and require used ('all'
or 'any')"),
{NULL}
};
@@ -90,6 +243,135 @@
}
}
+static int find_allowdeny(request_rec *r, apr_array_header_t *a, int
method)
+{
+
+ allowdeny *ap = (allowdeny *) a->elts;
+ apr_int64_t mmask = (AP_METHOD_BIT << method);
+ int i;
+ int gothost = 0;
+ const char *remotehost = NULL;
+
+ for (i = 0; i < a->nelts; ++i) {
+ if (!(mmask & ap[i].limited)) {
+ continue;
+ }
+
+ switch (ap[i].type) {
+ case T_ENV:
+ if (apr_table_get(r->subprocess_env, ap[i].x.from)) {
+ return 1;
+ }
+ break;
+
+ case T_ALL:
+ return 1;
+
+ case T_IP:
+ if (apr_ipsubnet_test(ap[i].x.ip,
r->connection->remote_addr)) {
+ return 1;
+ }
+ break;
+
+ case T_HOST:
+ if (!gothost) {
+ int remotehost_is_ip;
+
+ remotehost = ap_get_remote_host(r->connection,
+ r->per_dir_config,
+ REMOTE_DOUBLE_REV,
+ &remotehost_is_ip);
+
+ if ((remotehost == NULL) || remotehost_is_ip) {
+ gothost = 1;
+ }
+ else {
+ gothost = 2;
+ }
+ }
+
+ if ((gothost == 2) && in_domain(ap[i].x.from, remotehost))
{
+ return 1;
+ }
+ break;
+
+ case T_FAIL:
+ /* do nothing? */
+ break;
+ }
+ }
+
+ return 0;
+}
+
+static int ap_satisfies(request_rec *r)
+{
+ authz_host_dir_conf *conf = (authz_host_dir_conf *)
+ ap_get_module_config(r->per_dir_config, &authz_host_module);
+
+ return conf->satisfy[r->method_number];
+}
+
+static int check_dir_access(request_rec *r)
+{
+ int method = r->method_number;
+ int ret = OK;
+ authz_host_dir_conf *a = (authz_host_dir_conf *)
+ ap_get_module_config(r->per_dir_config, &authz_host_module);
+
+ if (a->order[method] == ALLOW_THEN_DENY) {
+ ret = HTTP_FORBIDDEN;
+ if (find_allowdeny(r, a->allows, method)) {
+ ret = OK;
+ }
+ if (find_allowdeny(r, a->denys, method)) {
+ ret = HTTP_FORBIDDEN;
+ }
+ }
+ else if (a->order[method] == DENY_THEN_ALLOW) {
+ if (find_allowdeny(r, a->denys, method)) {
+ ret = HTTP_FORBIDDEN;
+ }
+ if (find_allowdeny(r, a->allows, method)) {
+ ret = OK;
+ }
+ }
+ else {
+ if (find_allowdeny(r, a->allows, method)
+ && !find_allowdeny(r, a->denys, method)) {
+ ret = OK;
+ }
+ else {
+ ret = HTTP_FORBIDDEN;
+ }
+ }
+
+ /*
+ if (ret == HTTP_FORBIDDEN
+ && (ap_satisfies(r) != SATISFY_ANY ||
!ap_some_auth_required(r))) {
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ "client denied by server configuration: %s",
+ r->filename);
+ }
+ */
+
+ if (ret == HTTP_FORBIDDEN) {
+ /* If Satisfy is Any and authorization is required,
then make a
+ note of it and defer to the authorization stage */
+ if ((ap_satisfies(r) == SATISFY_ANY) &&
ap_some_auth_required(r)) {
+ apr_table_setn(r->notes,
AUTHZ_ACCESS_FAILED_NOTE, "Y");
+ return OK;
+ }
+ else {
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ "client denied by
server configuration: %s",
+ r->filename);
+ }
+ }
+
+ return ret;
+}
+
static authz_status env_check_authorization(request_rec *r, const char
*require_line)
{
const char *t, *w;
@@ -252,6 +534,9 @@
&authz_host_provider);
ap_register_provider(p, AUTHZ_PROVIDER_GROUP, "all", "0",
&authz_all_provider);
+
+ /* This can be access checker since we don't require r->user to be
set. */
+
ap_hook_access_checker(check_dir_access,NULL,NULL,APR_HOOK_MIDDLE);
}
module AP_MODULE_DECLARE_DATA authz_host_module =
Index: modules/aaa/mod_authz_default.c
===================================================================
--- modules/aaa/mod_authz_default.c (revision 368081)
+++ modules/aaa/mod_authz_default.c (working copy)
@@ -25,6 +25,9 @@
#include "http_protocol.h"
#include "http_request.h"
+#include "mod_auth.h"
+
+
typedef struct {
int authoritative;
} authz_default_config_rec;
@@ -53,7 +56,14 @@
{
authz_default_config_rec *conf =
ap_get_module_config(r->per_dir_config,
&authz_default_module);
+ const char *note = apr_table_get(r->notes,
AUTHZ_ACCESS_FAILED_NOTE);
+ /* If we got here and there isn't any authz required and there
is no
+ note from the access checker that it failed, assume access
is OK */
+ if (!ap_some_auth_required(r) && note) {
+ return OK;
+ }
+
if (!(conf->authoritative)) {
return DECLINED;
}
Index: modules/aaa/mod_auth.h
===================================================================
--- modules/aaa/mod_auth.h (revision 368081)
+++ modules/aaa/mod_auth.h (working copy)
@@ -42,6 +42,7 @@
#define AUTHZ_GROUP_NOTE "authz_group_note"
#define AUTHN_PROVIDER_NAME_NOTE "authn_provider_name"
#define AUTHZ_PROVIDER_NAME_NOTE "authz_provider_name"
+#define AUTHZ_ACCESS_FAILED_NOTE "authz_access_failed"
typedef enum {
AUTH_DENIED,
Re: Merging branch authz-dev - Authorization and Access
Control 2.3vs. 2.2
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 1/11/2006 at 3:43:36 pm, in message <43...@apache.org>,
rpluem@apache.org wrote:
>
> On 01/11/2006 11:23 PM, Roy T. Fielding wrote:
>> On Jan 11, 2006, at 7:19 AM, Joshua Slive wrote:
>>
>>> [Your merge today prompted me to dig out a response I started but
>>> never finished.]
>>>
>>> I am still worried that we are underestimating the pain that this will
>>> cause. In my opinion, a config change that requires substantial
>>> changes to every httpd.conf and many .htaccess files requires a major
>>> version bump (to 3.0) unless it can, in some way, be made seamless to
>>> the end user. And there is no way to deny that this will put a large
>>> roadblock in the way of upgraders.
>>
>>
>> It isn't just your opinion -- incompatible configuration changes
>> means third-parties have to change their source code, which means a
>> major version bump is required. So either somebody gets busy on
>> implementing backward-compatibility or this stuff gets bumped to 3.x.
>
> +1
>
> Regards
>
> Rüdiger
I'm looking for help. I obviously don't have all of the answers :)
Brad
Re: Merging branch authz-dev - Authorization and Access Control 2.3
vs. 2.2
Posted by Ruediger Pluem <rp...@apache.org>.
On 01/11/2006 11:23 PM, Roy T. Fielding wrote:
> On Jan 11, 2006, at 7:19 AM, Joshua Slive wrote:
>
>> [Your merge today prompted me to dig out a response I started but
>> never finished.]
>>
>> I am still worried that we are underestimating the pain that this will
>> cause. In my opinion, a config change that requires substantial
>> changes to every httpd.conf and many .htaccess files requires a major
>> version bump (to 3.0) unless it can, in some way, be made seamless to
>> the end user. And there is no way to deny that this will put a large
>> roadblock in the way of upgraders.
>
>
> It isn't just your opinion -- incompatible configuration changes
> means third-parties have to change their source code, which means a
> major version bump is required. So either somebody gets busy on
> implementing backward-compatibility or this stuff gets bumped to 3.x.
+1
Regards
Rüdiger
Re: Merging branch authz-dev - Authorization and Access Control 2.3 vs. 2.2
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jan 11, 2006, at 7:19 AM, Joshua Slive wrote:
> [Your merge today prompted me to dig out a response I started but
> never finished.]
>
> I am still worried that we are underestimating the pain that this will
> cause. In my opinion, a config change that requires substantial
> changes to every httpd.conf and many .htaccess files requires a major
> version bump (to 3.0) unless it can, in some way, be made seamless to
> the end user. And there is no way to deny that this will put a large
> roadblock in the way of upgraders.
It isn't just your opinion -- incompatible configuration changes
means third-parties have to change their source code, which means a
major version bump is required. So either somebody gets busy on
implementing backward-compatibility or this stuff gets bumped to 3.x.
We could decide that the next release will be 3.0, but I doubt it.
....Roy
Re: Merging branch authz-dev - Authorization and Access Control 2.3
vs. 2.2
Posted by Paul Querna <ch...@force-elite.com>.
Joshua Slive wrote:
> [Your merge today prompted me to dig out a response I started but
> never finished.]
>
> I am still worried that we are underestimating the pain that this will
> cause. In my opinion, a config change that requires substantial
> changes to every httpd.conf and many .htaccess files requires a major
> version bump (to 3.0) unless it can, in some way, be made seamless to
> the end user. And there is no way to deny that this will put a large
> roadblock in the way of upgraders.
I would personally prefer spending a little time and adding some code to
handle the old configurations with the new code. Maybe spit out some
warnings to the log, but hard breaks in the config suck. Authn did it
for more complicated handlers like ldap, but the basic file
configuration worked without modification.
-Paul
> On 1/6/06, Brad Nicholes <bn...@novell.com> wrote:
>> I believe that this could probably be done. Basically "Allow from"
>> was split into the 'IP', 'Host', etc. providers because that is how it
>> was represented in the source code and it just naturally fell out that
>> way.
>
> From a code perspective, I understand. But the directives should be
> structured from a user perspective as much as possible. I'd prefer to
> see just the "host".
>
>> Honestly, I struggled with this naming myself but really couldn't
>> come up with anything better that would accurately represent "Allow from
>> all" or "Deny from all" and still fit the authz provider model. I'm not
>> sure that "Require host all"/"Reject host all" quite fits it either
>> because we aren't always talking about a host.
>
> But using host maps very well to how people currently think about
> this. Host is the base access control method and other things are
> generally built on top. Again, I'd prefer to see this folded back
> into host.
>
>>> 4. It isn't made clear anywhere whether RequireAll or RequireOne is
>> the
>>> default.
>> Yeah it probably needs to be stated somewhere, however the default
>> is <RequireOne> basically because that is how it works today if you use
>> multiple Require directives. I guess I kind of expected that to be
>> obvious.
>
> Well, very few people use multiple require directives, so I don't
> think it is so obvious. And the default to the old Satisfy directive
> is All, which is equivalent to <SatisfyAll>. Obviously there is no
> way to keep both of these old behaviors, so it winds up being a major
> change either way.
>
> Joshua.
Re: Merging branch authz-dev - Authorization and Access Control 2.3 vs. 2.2
Posted by Joshua Slive <jo...@slive.ca>.
[Your merge today prompted me to dig out a response I started but
never finished.]
I am still worried that we are underestimating the pain that this will
cause. In my opinion, a config change that requires substantial
changes to every httpd.conf and many .htaccess files requires a major
version bump (to 3.0) unless it can, in some way, be made seamless to
the end user. And there is no way to deny that this will put a large
roadblock in the way of upgraders.
On 1/6/06, Brad Nicholes <bn...@novell.com> wrote:
> I believe that this could probably be done. Basically "Allow from"
> was split into the 'IP', 'Host', etc. providers because that is how it
> was represented in the source code and it just naturally fell out that
> way.
From a code perspective, I understand. But the directives should be
structured from a user perspective as much as possible. I'd prefer to
see just the "host".
> Honestly, I struggled with this naming myself but really couldn't
> come up with anything better that would accurately represent "Allow from
> all" or "Deny from all" and still fit the authz provider model. I'm not
> sure that "Require host all"/"Reject host all" quite fits it either
> because we aren't always talking about a host.
But using host maps very well to how people currently think about
this. Host is the base access control method and other things are
generally built on top. Again, I'd prefer to see this folded back
into host.
> > 4. It isn't made clear anywhere whether RequireAll or RequireOne is
> the
> > default.
>
> Yeah it probably needs to be stated somewhere, however the default
> is <RequireOne> basically because that is how it works today if you use
> multiple Require directives. I guess I kind of expected that to be
> obvious.
Well, very few people use multiple require directives, so I don't
think it is so obvious. And the default to the old Satisfy directive
is All, which is equivalent to <SatisfyAll>. Obviously there is no
way to keep both of these old behaviors, so it winds up being a major
change either way.
Joshua.