Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
Chris Darroch wrote: I've been working with the 2.4 authn/z stuff a bit lately and what I keep tripping over is that the default authorization merge rule uses OR logic. For example, if I enable mod_access_compat and put in a traditional: I wonder if anyone would offer a fastfeather talk next week on wed or thurs - it's only 15 minutes - to introduce what's upcoming in 2.4? Bill
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
William A. Rowe, Jr. wrote: I've been working with the 2.4 authn/z stuff a bit lately and what I keep tripping over is that the default authorization merge rule uses OR logic. For example, if I enable mod_access_compat and put in a traditional: I wonder if anyone would offer a fastfeather talk next week on wed or thurs - it's only 15 minutes - to introduce what's upcoming in 2.4? I won't be there, but here's a recap of the issue for discussion. (Caveat: I may be missing something important!) With 2.2 and prior versions, one can do something like: Directory /htdocs Require valid-user /Directory Directory /htdocs/admin Require user admin /Directory The logic which is then applied is: 1) For all requests under /htdocs, except those under /htdocs/admin, require any valid user. 2) For all requests under /htdocs/admin, require the admin user. With 2.4, unless I'm missing something, the same configuration produces the logic: 1) For all requests under /htdocs, except those under /htdocs/admin, require any valid user. 2) For all requests under /htdocs/admin, require any valid user OR require the user admin. Of course this grants any valid user access. To get the old behaviour, you seem to need to add AuthzMergeRules Off to the second Directory. I just tested versions of this configuration with 2.2 and 2.4 and I think I'm describing the situation correctly. Assuming I am, I fear this will surprise a lot of people who think they've secured their systems after upgrading. It certainly caught me short. Perhaps the default AuthzMergeRules setting should be Off rather than On, at least when merging across configuration blocks? Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
-Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Donnerstag, 3. April 2008 16:07 An: dev@httpd.apache.org Betreff: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?]) Another good topic of discussion: Time for a 2.4 release? I wouldn't mind pushing that along and get some of the feature-set of 2.4 out before we do too much ripping with the inevitable delays associated with that :) I know that I am always devils advocate and a brakeman regarding this, but we should keep in mind the following: 1. After the rewrite of the authz code to a provider based model we still fail the basic authz tests in the perl framework. This is a clear showstopper and needs to be fixed first. Yes, I also should have a had a more closer look on what Brad (no blame game intended against anyone as I failed to do proper review back then) did there in the past to highlight issues earlier, but my gut feeling tells me that there are still some surprises in this code regarding bugs and the configuration syntax. 2. My feeling regarding the usage of 2.2 is that since about 6 month we are getting track as commercial 3rd parties now supply modules for httpd 2.2. This means that will have to maintain one more stable branch for quite some time and to be honest currently we effectively manage only one since 1.3 and also 2.0 seem to be pretty abandoned. I am not quite sure if we have enough resources to do this. Regards Rüdiger
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
On Thu, Apr 03, 2008 at 10:06:50AM -0400, Jim Jagielski wrote: Time for a 2.4 release? I wouldn't mind pushing that along and get some of the feature-set of 2.4 out before we do too much ripping with the inevitable delays associated with that :) Is there really enough news in trunk to warrant the overhead of maintaining yet another branch? tbh. I'd much rather see work going towards 3.x ;) vh Mads Toftum -- http://soulfood.dk
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
Plüm wrote:
2. My feeling regarding the usage of 2.2 is that since about 6 month we are
getting
track as commercial 3rd parties now supply modules for httpd 2.2. This means
that
will have to maintain one more stable branch for quite some time and to be
honest
currently we effectively manage only one since 1.3 and also 2.0 seem to be
pretty
abandoned. I am not quite sure if we have enough resources to do this.
Perhaps 1.3 is maintained, perhaps not, just depending on if there
are enough developers who care to provide minor patches. But it
really shouldn't be a distraction.
Once folks accept 2.2 as a clean replacement for 2.0 (we are essentially
there now, I think, perhaps after one or two more point-bumps), 2.0 should
fall off the radar entirely.
This 2.2 becomes stable, so we are really only talking about supporting
a 2.2 and a 2.4 for a while, then 2.4 and a 3.0.
I'd -1 a 2.4.0 release today, because nobody has even bothered to make
a candidate for 2.3-dev. Auth logic changes break most if not all third
party auth modules (broke an auth feature in mod_ftp). Not talking about
commercial modules but every third party auth extension out there.
The only thing I'd like to change before we push 2.3-dev onto our module
developer community is to enhance the methods logic (64 is now insufficient
when you add DAV + FTP + {whatever} into the method stew) and drop the
Limit directive already for the Method directive. These have some
subtle auth-changes that a few auth module authors need to compensate for.
(The third party auth modules that won't change are the ones that are
already broken for Limit ... who won't have to do anything special in
support of the Method directive.)
I'll commit the Method changes before the hackathon so that folks can
corner me in person, dev@ list feedback will also be welcome as always.
Just to prove I'm not being a prick with respect to Lua support, I'm working
on Method as an add in module ;-)
Bill
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
On 4/3/08 10:47 AM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: I'll commit the Method If HTTP_Method == GET ... /If ;) -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
Akins, Brian wrote: On 4/3/08 10:47 AM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: I'll commit the Method If HTTP_Method == GET ... /If Slow
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
On 4/3/08 11:38 AM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
If HTTP_Method == GET
...
/If
Slow
Not if the parsing is done at config time and HTTP_Method is handle by a
provider. Some pseudo code:
At config time, the parser would do something like:
parse_provider *prov;
void *data;
prov = ap_lookup_provider(config_parse, HTTP_Method, 0.1);
data = prov-init(conf_pool, HTTP_Method, TOKEN_EQUAL, GET)
/*the provider may do something like*/
typedef struct {
parse_token token;
int method_number;
} method_data;
void *method_init(apr_pool_t *pool, const char *key, parse_token token,
const char *arg) {
method_data *data = apr_pcalloc(pool, sizeof(method_data));
data-token = token; /*need to check if we only handle === or something
*/
if(strcacecmp(arg, GET)) {
data-method_number = M_GET;
}
return data;
/*the parser stores this data with the node*/
At run time, then when running this node from the cached parse tree, it may
call something like:
node-prov-exec(r, nod-data)
/*the provider runs something like*/
int method_exec(reuqest_rec *r, method_data *data) {
if(data-method_number == r-method_number)
return 1;
return 0;
}
Very rough draft. But this is not necessarily slow... ;)
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
On Thu, Apr 3, 2008 at 8:53 AM, Akins, Brian [EMAIL PROTECTED] wrote: Very rough draft. But this is not necessarily slow... ;) Right. Even then, the user/admin may be willing to burn CPU cycles anyway to get a simpler config. Plus, if they were to use mod_rewrite, they've already blown a huge chunk of CPU cycles! =) -- justin
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
On Thu, Apr 3, 2008 at 4:31 PM, Mads Toftum [EMAIL PROTECTED] wrote: On Thu, Apr 03, 2008 at 10:06:50AM -0400, Jim Jagielski wrote: Time for a 2.4 release? I wouldn't mind pushing that along and get some of the feature-set of 2.4 out before we do too much ripping with the inevitable delays associated with that :) Is there really enough news in trunk to warrant the overhead of maintaining yet another branch? tbh. I'd much rather see work going towards 3.x ;) vh Mads Toftum -- http://soulfood.dk I'm wondering the same. -- ~Jorge
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
Nick Kew wrote: Limit is of course a crusty old relative. Limit is unrelated, it's fundamentally borked (directive must know it is participating in a limit-ed section, cannot overly multiple limit-ed sections because that directive has never created a conf section, and there is no exception thrown when a non-participating directive is nested within a limit). This is why I'm not 'fixing' Limit ... there are simply too many broken configs out there. Bill
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
Justin Erenkrantz wrote: On Thu, Apr 3, 2008 at 8:53 AM, Akins, Brian [EMAIL PROTECTED] wrote: Very rough draft. But this is not necessarily slow... ;) Right. Even then, the user/admin may be willing to burn CPU cycles anyway to get a simpler config. Plus, if they were to use mod_rewrite, they've already blown a huge chunk of CPU cycles! =) -- justin Yes! I'm not against offering slow features :) I'm only antagonistic towards replacing the fast ones, from today. FYI - Files and Directory should be entirely moved out of core into our default filesystem provider module. Only host/location/method should be part of the core (well, host perhaps in the http layer). The If logic doesn't even apply when that module isn't loaded, I'd hope. Those admins who refuse to let their junior admins use that directive should have a level of control over their outward facing heavily-loaded machines :)
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
On Thu, 03 Apr 2008 11:13:31 -0500 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: The If logic doesn't even apply when that module isn't loaded, I'd hope. Those admins who refuse to let their junior admins use that directive should have a level of control over their outward facing heavily-loaded machines :) The If logic is approximately cloned from Files, and just differs in what it evaluates. If we're talking about any substantial config changes, then the whole location_walk and merges should be on the table. But before that, we need a vision of where we're going, and how to get there without breaking what we've got. I don't see any such vision in this discussion. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
On 4/3/2008 at 8:23 AM, in message [EMAIL PROTECTED], Plüm, Rüdiger, VF-Group [EMAIL PROTECTED] wrote: -Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Donnerstag, 3. April 2008 16:07 An: dev@httpd.apache.org Betreff: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?]) Another good topic of discussion: Time for a 2.4 release? I wouldn't mind pushing that along and get some of the feature-set of 2.4 out before we do too much ripping with the inevitable delays associated with that :) I know that I am always devils advocate and a brakeman regarding this, but we should keep in mind the following: 1. After the rewrite of the authz code to a provider based model we still fail the basic authz tests in the perl framework. This is a clear showstopper and needs to be fixed first. Yes, I also should have a had a more closer look on what Brad (no blame game intended against anyone as I failed to do proper review back then) did there in the past to highlight issues earlier, but my gut feeling tells me that there are still some surprises in this code regarding bugs and the configuration syntax. It wouldn't surprise me, which is why we need to get a 2.3-beta out there for testing. I've tried to make sure that the holes where filled with the authz refactor, but it is likely that something will be missing until more wide spread testing is done. The perl framework problems were discussed on the list a couple of months ago http://mail-archives.apache.org/mod_mbox/httpd-dev/200801.mbox/[EMAIL PROTECTED] The current tests don't apply anymore because authz has moved from hook based to provider based with logic operators added. If we need to rework something outside of the tests themselves, then that needs to be identified. As far as breaking existing authz modules, it is a similar situation when authn moved from hooks to providers in 2.2. All of the standard Apache authz modules have already been refactored. This issue is third parties will have to refactor their authz modules for 2.4. Brad
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
Nick Kew wrote: But before that, we need a vision of where we're going, and how to get there without breaking what we've got. * server_conf goes away. Modules have zero or more conf sections, essentially today's misnamed dir_conf, which are initialized and merged as they are today. Either using simple-wrappers or custom. * we lose nothing, any module can rerun the conf merge conditionally (see mod_proxy today, or method, or the new if implementation). * modules may pre-merge things to optimize them. E.g. mod_vhost will pre-merge all of our VirtualHosts such that there is no run time penalty for vhosts. * particular merges should remain, as they are today, as a modular assemblage of features. If your server will never serve files, there is no reason to compile in mod_filesystem e.g. Files and Dir mergers. No mod_vhost? Then no VirtualHost support. *** there must be sufficient hooks so that a lua, perl or m4 wrapper can participate in parsing the config. TBD if that exists today. I don't see any such vision in this discussion. Go back to my post from last night. Not saying there's agreement, just some vision. I know folks are thinking wow, I want to put my favorite [Lua] language parser into httpd core! Well that's fine for some users, but at the very same time, you have a huge crowd of perl users, mod_macro users, etc. Based on httpd's design, you are SUPPOSED to be able to plug whichever wrapper you like into the core. Overloading the core is taking httpd into an entirely different direction. Just look at the effort we've already expended is splitting cache from proxy, auth components from one another, proxy capabilities from one monolithic module. For that matter, plug in an XML syntax parser. We aren't quite there because we don't have the concept of named-arguments. Fix that across the entire spectrum of modules. E.g. instead of TAKE2, we have some tuple for alias such as (TAKE2, uri-path, file-path, NULL) which will facilitate more deliberate parsers and conf authoring. And that is without breaking today's syntax. Bill
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
William A. Rowe, Jr. wrote: I'd -1 a 2.4.0 release today, because nobody has even bothered to make a candidate for 2.3-dev. Auth logic changes break most if not all third party auth modules (broke an auth feature in mod_ftp). Not talking about commercial modules but every third party auth extension out there. I've been working with the 2.4 authn/z stuff a bit lately and what I keep tripping over is that the default authorization merge rule uses OR logic. For example, if I enable mod_access_compat and put in a traditional: Location /foo Order deny,allow Deny from all /Location it doesn't take effect, because the default top-level Directory contains Require all granted and since that succeeds for all requests, everything else is short-circuited by the OR merge logic. So at a minimum I seem to have to put in an AuthzMergeRules Off to get things to DWIM. I fear that might trip up a significant percentage of people upgrading ... perhaps a AuthzMergeRules Off in the default httpd.conf would be sufficient, but my experience with mod_authz_dbd suggested that I needed to put it in a lot of places to get stuff working the way I intended (e.g., the example config in the mod_authz_dbd manual page in the trunk docs). Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
On Apr 3, 2008, at 12:32 PM, Brad Nicholes wrote: It wouldn't surprise me, which is why we need to get a 2.3-beta out there for testing. That would be good as well... that way we can determine how solid the existing impl is, so when the new stuff is added we know the old stuff is still good :)
