Re: Netware proxy makefiles and USE_STDSOCKETS
Rainer, It has actually been quite a while since I have been on this list. I did most of the initial Netware port of Apache. Apache for Netware uses its own implementation of Winsock as the socket layer. This is the reason why the make files specify not to use the standard sockets. The Netware version of Winsock also has it's own implementation of SSL which is why most of the time mod_ssl is not used by Apache for Netware. Basically, the Apache for Netware make files should always be building with Winsock. thanks, Brad > Rainer, > Apologies for the silence, but my major focus ATM is getting my place > fixed up with the view to moving, but did have a go at a build with the > USE_STDSOCKETS but something appears to be broken in apr-1.5, but have > not yet had a chance to look into it. Medical visit this morning and if > I get home soon enough will look further at it. > > FTM, > Norm > PS If GK is reading this he might have a look at it, but don't hold your > breath.
Re: AuthBasicProvider failover and mod_authnz_ldap
On 7/13/2009 at 3:31 PM, in message 1404e5910907131431m42ec4cffwc08caf273b71f...@mail.gmail.com, Eric Covener cove...@gmail.com wrote: PR#47521 points out that when mod_authnz_ldap has some fatal LDAP connectivity error, it doesn't allow other AuthBasicProviders to have a shot at checking the userid. It seems like the normal use case for two providers is when there are two disjoint user repositories, and we only move on to search the second when the user of interest isn't found in the first. For LDAP, should we treat a failure to even search the database this same way, allowing it to move onto other providers (AUTH_USER_NOT_FOUND vs. AUTH_GENERAL_ERROR)? It seems to me that the LDAP backends often have poor reliability and lots of use cases would want the 2nd provider for emergencies, at little expense (hypothetical attacker that took out your LDAP servers, and compromised e.g. AuthUserFile). Thoughts? There are actually two issues to consider in the context of PR#47521. The first issue is what should mod_authn_alias do if it gets an AUTH_GENERAL_ERROR vs AUTH_USER_NOT_FOUND. Apparently, according to the bug, mod_authn_alias just stops which is probably what the intention was when I coded it (years ago in another lifetime ;) . The question here is given this context, should AUTH_GENERAL_ERROR == AUTH_USER_NOT_FOUND? Given this context, the answer is probably yes. However are there any cases dealing with authn_alias where the answer should be no? The second issue is what should authnz_ldap do? Authnz_ldap has already been coded for redundancy if it is configured for it. If there is a problem in this case, then it is a bug that should be looked at. Brad
Re: criteria for axing MPMs from the tree
On 3/26/2009 at 11:14 AM, in message 49cbb7d9.80...@rowe-clan.net, William A. Rowe, Jr. wr...@rowe-clan.net wrote: traw...@gmail.com wrote: Votes: [+1] yank BeOS MPM from trunk [+1] yank OS/2 MPM from trunk and for completeness [+1] yank Netware from trunk Netware is 'done' - surely some will use it for another 5 years but not for 'new software'. Their 2.2 build is sufficient IMHO. A totally separate vote/discussion is required on d...@apr. FWIW, netware still builds and runs in trunk. If you yank the MPM, then I guess netware really will be done. :( Brad
Re: criteria for axing MPMs from the tree
On 3/26/2009 at 11:55 AM, in message 49cb6d2b02ac0003c...@lucius.provo.novell.com, Brad Nicholes bnicho...@novell.com wrote: On 3/26/2009 at 11:14 AM, in message 49cbb7d9.80...@rowe-clan.net, William A. Rowe, Jr. wr...@rowe-clan.net wrote: traw...@gmail.com wrote: Votes: [+1] yank BeOS MPM from trunk [+1] yank OS/2 MPM from trunk and for completeness [+1] yank Netware from trunk Netware is 'done' - surely some will use it for another 5 years but not for 'new software'. Their 2.2 build is sufficient IMHO. A totally separate vote/discussion is required on d...@apr. FWIW, netware still builds and runs in trunk. If you yank the MPM, then I guess netware really will be done. :( Just to follow up. Apache 2.0.x for NetWare is the only version that is still shipping on the NetWare platform. I am not sure if anybody is really using Apache 2.2.x for NetWare or not. I expect that there are a few loyal NetWare fans out there that upgraded to 2.2 on there own. Apache 2.3.x and beyond, no plans to use it, ship it and I can only really maintain it to make sure that things still build and appear to run correctly. So basically, if you all decide to pull the NetWare MPM, then I guess I don't have to worry about maintaining apache for NetWare beyond 2.2.x. Brad
Re: criteria for axing MPMs from the tree
On 3/26/2009 at 12:07 PM, in message cc67648e0903261107l1302f629k95494e01834c6...@mail.gmail.com, Jeff Trawick traw...@gmail.com wrote: On Thu, Mar 26, 2009 at 7:05 PM, Brad Nicholes bnicho...@novell.com wrote: On 3/26/2009 at 11:55 AM, in message 49cb6d2b02ac0003c...@lucius.provo.novell.com, Brad Nicholes bnicho...@novell.com wrote: On 3/26/2009 at 11:14 AM, in message 49cbb7d9.80...@rowe-clan.net, William A. Rowe, Jr. wr...@rowe-clan.net wrote: traw...@gmail.com wrote: Votes: [+1] yank BeOS MPM from trunk [+1] yank OS/2 MPM from trunk and for completeness [+1] yank Netware from trunk Netware is 'done' - surely some will use it for another 5 years but not for 'new software'. Their 2.2 build is sufficient IMHO. A totally separate vote/discussion is required on d...@apr. FWIW, netware still builds and runs in trunk. If you yank the MPM, then I guess netware really will be done. :( Just to follow up. Apache 2.0.x for NetWare is the only version that is still shipping on the NetWare platform. I am not sure if anybody is really using Apache 2.2.x for NetWare or not. I expect that there are a few loyal NetWare fans out there that upgraded to 2.2 on there own. Apache 2.3.x and beyond, no plans to use it, ship it and I can only really maintain it to make sure that things still build and appear to run correctly. So basically, if you all decide to pull the NetWare MPM, then I guess I don't have to worry about maintaining apache for NetWare beyond 2.2.x. You pull the trigger then ;) Pull it. It's been a good run and I really had a lot of fun porting and maintaining Apache for NetWare. But I guess it's time to say goodbye (to Apache for NetWare, not me ;) I will try to hang around and maintain the older versions, if anything needs to be maintained. If there is anything that comes up with Apache for the Linux platform that I can help with, I will certainly do my best. But I guess going forward, if Apache for NetWare ever becomes relevant again, I'll just pick it up and port it like I did before. But I really don't see that happening. Brad
Re: [VOTE] Release Apache HTTP server 2.2.11
On 12/6/2008 at 9:30 AM, in message [EMAIL PROTECTED], Ruediger Pluem [EMAIL PROTECTED] wrote: Test tarballs for Apache httpd 2.2.11 are available at: http://httpd.apache.org/dev/dist/ Your votes please; +/-1 [ ] Release httpd-2.2.11 as GA Regards Rüdiger +1 NetWare Brad
Re: AuthzMergeRules blocks everything in default configuration
On 12/4/2008 at 1:30 PM, in message [EMAIL PROTECTED], Chris Darroch [EMAIL PROTECTED] wrote: Hi -- Eric Covener wrote: I had meant iif containers are used, I'd like their name to communicate the require or reject part while the authz providers would be match-like (because the Require on the inside is confusing when surrounted by all the variations) Yes, I thought that was a good point; my further thought was that the container names can't imply require/reject either though, because they can be nested and so their meaning can be inverted if they're contained in a negated context. Roy T. Fielding wrote: But we are already using *Match all over the place to indicate the use of regex matching. :( These are good points; I hadn't thought of the overlap with LocationMatch and friends. A lot of the other obvious access-control-related words and terms are also already in use, especially for older authorization directives (e.g., Allow, Deny, Order, Limit, Require, Satisfy, etc.) In order to avoid confusion, we should probably stay away from all of these too. Perhaps something like Check or Test would suffice, maybe prefixed with Authz? Hopefully someone else has a good idea, or at least stronger opinions. :-) I think prefixing it with Authz probably makes more sense. Brad
Re: svn commit: r709839 - in /httpd/httpd/trunk: ./ build/ modules/aaa/modules/arch/netware/ os/netware/ os/win32/
On 11/1/2008 at 10:21 PM, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Author: chrisd Date: Sat Nov 1 21:21:48 2008 New Revision: 709839 URL: http://svn.apache.org/viewvc?rev=709839view=rev Log: Remove mod_authn_default and mod_authz_default. Note: I've attempted to work through the Windows and Netware build files, but if those with such systems could repair any damage, that would be appreciated. Removed: httpd/httpd/trunk/modules/aaa/mod_authn_default.c httpd/httpd/trunk/modules/aaa/mod_authn_default.dsp httpd/httpd/trunk/modules/aaa/mod_authz_default.c httpd/httpd/trunk/modules/aaa/mod_authz_default.dsp httpd/httpd/trunk/modules/arch/netware/mod_authn_default.def httpd/httpd/trunk/modules/arch/netware/mod_authz_default.def Modified: httpd/httpd/trunk/Apache.dsw httpd/httpd/trunk/CHANGES httpd/httpd/trunk/Makefile.win httpd/httpd/trunk/NWGNUmakefile httpd/httpd/trunk/build/installwinconf.awk httpd/httpd/trunk/build/mkconfNW.awk httpd/httpd/trunk/modules/aaa/config.m4 httpd/httpd/trunk/os/netware/modules.c httpd/httpd/trunk/os/win32/BaseAddr.ref I haven't tried out the new authnz directives yet, but it at least builds on NetWare. Brad
Re: svn commit: r667651 - /httpd/httpd/trunk/modules/aaa/mod_authz_core.c
On 7/11/2008 at 5:30 PM, in message [EMAIL PROTECTED], Roy T. Fielding [EMAIL PROTECTED] wrote: On Jul 11, 2008, at 2:14 PM, Brad Nicholes wrote: On 7/11/2008 at 12:01 PM, in message [EMAIL PROTECTED], David Shane Holden [EMAIL PROTECTED] wrote: Thanks for the link and description Brad. It makes sense now. Explains why the default config was giving me a 403. The 'Require all denied' was being inherited from the root directory config. Would it be appropriate to add something like the attached patched to httpd.conf.in? In this case, probably. The default needs to be off. We can't disable sites on an upgrade within the 2.x series. Roy So this was really the question that was being discussed especially in the last few messages of the thread http://www.mail-archive.com/dev%40httpd.apache.org/msg40286.html. Is it better to switch the default to ON knowing that 2.4 might disable some sites based on stricter auth rules, or leave the default at OFF knowing that there might be some holes left open? Maybe the justification is that the holes where always there anyway and being plugged by extra auth configuration prior to 2.4, so 2.4 really doesn't need to enforce stricter auth rules. I intentionally wrote the patch so that both the defaults for the AuthzMergeRules directive and the initial merge rule, can be easily switched. I would just ask that those concerned read through the message thread and determine what the defaults should be. I can see pros and cons of each but I can go with whatever makes sense to the user. Brad Brad
Re: svn commit: r667651 - /httpd/httpd/trunk/modules/aaa/mod_authz_core.c
See inline comments below.
Brad
On 7/11/2008 at 12:26 AM, in message [EMAIL PROTECTED], David Shane
Holden [EMAIL PROTECTED] wrote:
I tried to build Apache from trunk tonight and noticed that this patch
broke something. I'm getting a 403 error when trying to browse to a
clean install. I'm by no means an expert here, but I noticed a few
things which are noted below...
[EMAIL PROTECTED] wrote:
Author: bnicholes
Date: Fri Jun 13 13:59:10 2008
New Revision: 667651
URL: http://svn.apache.org/viewvc?rev=667651view=rev
Log:
Switch the default base authz logic operation to 'AND' rather than 'OR'.
This should allow directory authz rules merging to be more restrictive in
sub-directories
Modified:
httpd/httpd/trunk/modules/aaa/mod_authz_core.c
Modified: httpd/httpd/trunk/modules/aaa/mod_authz_core.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/aaa/mod_authz_core.c?r
ev=667651r1=667650r2=667651view=diff
=
=
--- httpd/httpd/trunk/modules/aaa/mod_authz_core.c (original)
+++ httpd/httpd/trunk/modules/aaa/mod_authz_core.c Fri Jun 13 13:59:10 2008
@@ -111,13 +111,16 @@
static const char *merge_authz_provider(authz_core_dir_conf *conf,
authz_provider_list *newp);
static void walk_merge_provider_list(apr_pool_t *a, authz_core_dir_conf
*conf, authz_provider_list *providers);
+#define BASE_REQ_STATE AUTHZ_REQSTATE_ALL
+#define BASE_REQ_LEVEL 0
+
static void *create_authz_core_dir_config(apr_pool_t *p, char *dummy)
{
authz_core_dir_conf *conf =
(authz_core_dir_conf *)apr_pcalloc(p,
sizeof(authz_core_dir_conf));
-conf-req_state = AUTHZ_REQSTATE_ONE;
-conf-req_state_level = 0;
+conf-req_state = BASE_REQ_STATE;
+conf-req_state_level = BASE_REQ_LEVEL;
conf-merge_rules = 1;
return (void *)conf;
}
Not sure if this was intentional... but the default went from
authz_reqstate_one to authz_reqstate_all. If I change base_req_state to
authz_reqstate_one the 403 disappears, but since I don't know much about
how this is suppose to work it might not be the correct fix.
Yes, the switch from AUTHZ_REQSTATE_ONE to AUTHZ_REQSTATE_ALL was intentional.
It was also known that doing this might cause some problems for existing
configurations. But the switch was made to close up some security issues.
Take a look at this thread for a complete description of how things work and
why. http://www.mail-archive.com/dev%40httpd.apache.org/msg40286.html
@@ -180,11 +183,21 @@
/* Walk all of the elements recursively to allow each existing
element to be copied and merged into the final configuration.*/
-if (providers-one_next) {
-walk_merge_provider_list (a, conf, providers-one_next);
+if (BASE_REQ_STATE == AUTHZ_REQSTATE_ONE) {
+if (providers-one_next) {
+walk_merge_provider_list (a, conf, providers-one_next);
+}
+if (providers-all_next) {
+walk_merge_provider_list (a, conf, providers-all_next);
+}
}
-if (providers-all_next) {
-walk_merge_provider_list (a, conf, providers-all_next);
+else {
+if (providers-all_next) {
+walk_merge_provider_list (a, conf, providers-all_next);
+}
+if (providers-one_next) {
+walk_merge_provider_list (a, conf, providers-one_next);
+}
}
base_req_state == authz_reqstate_one will always fail. was this
comparison suppose to be conf-req_state == authz_reqstate_one?
No, the #define BASE_REQ_STATE was added so that the code could be easily
switched back to a default of AUTHZ_REQSTATE_ONE if testing proved that a
default of AUTHZ_REQSTATE_ALL was incorrect. With the default set to
AUTHZ_REQSTATE_ALL you are correct, this statement will always fail. But if
the default were switched back, then it makes sense. Once everything has been
tested and the correct default state has been determined, then this statement
can be cleaned up if necessary.
return;
@@ -200,18 +213,30 @@
authz_provider_list *last = conf-providers;
int level = conf-req_state_level;
-/* if the level is 0 then take care of the implicit 'or'
+/* if the level is the base level then take care of the implicit
* operation at this level.
*/
-if (level == 0) {
-/* Just run through the Require_one list and add the
- * node
- */
-while (last-one_next) {
-last = last-one_next;
+if (level == BASE_REQ_LEVEL) {
+if (conf-req_state == AUTHZ_REQSTATE_ONE) {
+/* Just run through the Require_one list and add the
+ * node
+ */
+while (last-one_next) {
+last = last-one_next;
+}
Re: svn commit: r667651 - /httpd/httpd/trunk/modules/aaa/mod_authz_core.c
On 7/11/2008 at 12:01 PM, in message [EMAIL PROTECTED], David Shane Holden [EMAIL PROTECTED] wrote: Thanks for the link and description Brad. It makes sense now. Explains why the default config was giving me a 403. The 'Require all denied' was being inherited from the root directory config. Would it be appropriate to add something like the attached patched to httpd.conf.in? In this case, probably. Brad
Re: [VOTE] Release Apache HTTP Server 2.2.9
On 6/10/2008 at 6:50 PM, in message [EMAIL PROTECTED], Jim Jagielski [EMAIL PROTECTED] wrote: Test tarballs for Apache httpd 2.2.9 are available at: http://httpd.apache.org/dev/dist/ Your votes please; +/-1 [ ] Release httpd-2.2.9 as GA DO NOT begin distributing these in any manner whatsoever, please note that you can seriously mess up any user who installs these packages if they are ultimately rejected. +1 NetWare
Re: AuthzMergeRules directive
On 4/18/2008 at 8:53 AM, in message [EMAIL PROTECTED], Chris Darroch [EMAIL PROTECTED] wrote: Brad Nicholes wrote: I could go along with switching the default merging rule from OR to AND, even within a dir block. The reason why it is OR today was basically for backward compatibility. Since there really wasn't any kind of logic before, OR was just the default. If we switch to AND as being the default within a dir block, it may break some existing configurations. However I also think that AND is a safer merging rule going forward. If we just switch the AuthzMergeRules default state to Off, and make On mean AND, that would be a great start. Then maybe we can revisit and take a look at what breaks if the within-block merging is AND too; if it breaks too much stuff, maybe it needs to stay OR. Right now I can't say I have an informed opinion on that. Thanks again for working through this stuff, Chris. After re-examining the code, the above suggestion is much easier said than done. The reason why is because base Directory logic starts from the AUTHZ_REQSTATE_ONE (OR) state. So if you have two Directory blocks, their respective per-dir structures are storing their authz logic as it was evaluated during configuration time. Then when the two Directory blocks are merged, they are merged according to current state. In other words, the following Directory block would be merged using OR: Directory /foo require user joe /Directory Directory /foo/bar authzmergerules on require user sue /Directory The reason why is because when the Directory blocks were first evaluated independently, the starting state was AUTHZ_REQSTATE_ONE. However in the following example the two Directory block will be merge with AND: Directory /foo require user joe /Directory Directory /foo/bar authzmergerules on satisfyall require user sue /satisfyall /Directory The reason why AND is used in this situation is because the satisfyall block in the subdirectory changed its starting state from AUTHZ_REQSTATE_ONE (OR) to AUTHZ_REQSTATE_ALL (AND). There isn't any way to insert a different merging operator. It is always the sub-directory that determines how it will be merged into its parent. So what I am really trying to say is that intra-block logic and inter-block logic as far as merging goes, are tied together. If we want to change the way that the logic of two block is merged, we would also have to change the base state of each independent block. It's all or nothing. This would affect how the following block is evaluated: Directory /foo require user joe require user sue /Directory As it currently stands, the logic when combining these two rules would be OR. If we make the change, this would also change the same configuration to use AND instead. I think we determined that this logic would be more secure anyway even if it is different than 2.2.x. thoughts? Brad
Building mod_auth_form...
Trying to build mod_auth_form.c just produces link errors. I can see where the optional function is imported as ap_session_set_fn() but then later referenced as ap_session_set(). The code should be changed to use one or the other right? Brad
Re: AuthzMergeRules directive
On 4/14/2008 at 3:29 PM, in message [EMAIL PROTECTED], Chris Darroch [EMAIL PROTECTED] wrote: Brad Nicholes wrote: This is where it starts to go wrong for me. Where it gets confusing for somebody who is trying to figure out what the configuration is doing is: Directory /www/pages SatisfyAll Require ip 10.10.0.1 Require ldap-group sales SatisfyOne Require ldap-group ne-sales Require ldap-group sw-sales /SatisfyOne /SatisfyAll /Directory Directory /www/pages/private AuthzMergeRules SatisfyOne SatisfyAll Require ldap-group marketing Require ldap-group alt-marketing /SatisfyAll /Directory Now I have to reconcile the logic of the parent with the logic of both the AuthzMergeRules and the SatisfyAll tag. Even though it might not always look like the cleanest configuration, I think it will be less confusing if the logic rules were confined to the SatisfyAll and SatisfyOne tags rather than introducing alternate logic directives. [snip] If you'd like to stick to just Off (my proposed default for AuthzMergeRules) and On, perhaps AND should be the logic implemented by On? Consider the following, where AND'ing helps tighten security as you go down the tree: [snip] Personally, I'm gradually coming around to the feeling that AND is more useful/secure than OR when merging per-dir blocks, and possibly even within a single per-dir block (although that's another conversation), and so should either be an option to AuthzMergeRules or the action implemented by On if there are only two states. The reason I say it might make sense to AND authz requirements within a block is that it reads a little more naturally. Consider the following, which suggests to me that I need a shirt and shoes to be served, not one or the other: Directory /www/service Require shirt on Require shoes on /Directory At rate rate, thanks for hashing through all my scattershot ideas on this stuff. I could go along with switching the default merging rule from OR to AND, even within a dir block. The reason why it is OR today was basically for backward compatibility. Since there really wasn't any kind of logic before, OR was just the default. If we switch to AND as being the default within a dir block, it may break some existing configurations. However I also think that AND is a safer merging rule going forward. Brad
Re: [PROPOSAL] Time Based Releases
On 4/15/2008 at 5:49 AM, in message [EMAIL PROTECTED], William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Jim Jagielski wrote: I think what Paul is suggesting (he will for sure correct me if I'm wrong) is that it's better to at least have some semblance of a schedule than not, and by baselining every X months for a release, it provides us, as volunteers, to better allocate time. It does not mean, imo, that we rush out packages that aren't ready or release something just because we have a schedule to keep... we all have day jobs that force that on us, and we don't want that kind of pressure here as well. However, looking over things, I think that we have enough active activity such that a ~3month cycle might be workable... IOW, if we declare a 2 month cycle, we end up with releases every three months ;-) I believe that it would benefit the project to do releases a little more frequently than we have in the past, I would just rather see the project release because a release is warranted. Not because a schedule dictates that we do it. I guess I have always liked the fact that Apache does things because it is the right thing to do, not because there is some artificial requirement. If Paul wants to release every two months, more power to him and to the project. Just do it, we shouldn't have to take a vote or change any of our existing written or unwritten policies. Maybe the real problem is that the Apache httpd project has lost some of the passion that it used to have. I think that is what Roy was saying in the Keynote slides that Paul forwarded to the list. Maybe the problem is that we have all become a little too conservative when it comes to releases because we have all realized just how much people depend on this little piece of software. However that conservative attitude only applies to the past, it shouldn't apply to the future. IOW, we may be required to be conservative when it comes to 1.3.x, 2.0.x or 2.2.x, but the same level of conservatism shouldn't apply to 2.4 or 3.0. It's been 3 1/2 years since we started the last major release cycle of the httpd server and 2 1/2 years since the last major release of the web server. That's longer than many if not most commercial products. So what, if some of the 2.3 features are not fully baked or if some things may not work quite right. Why should that stop the project from releasing something anyway, whatever that something might be. If it is adopted and accepted, then great. If it falls on its face then we know what not to do the next time. I know, I am probably preaching to the choir and it may even sound like I am arguing both sides of the subject line above. But if we want to get the passion back in the project, then it might be time for the project to take some more risks. Release because it is the right thing to do. Brad
Re: [PROPOSAL] Time Based Releases
On 4/12/2008 at 11:20 AM, in message [EMAIL PROTECTED], Paul Querna [EMAIL PROTECTED] wrote: This is something I have been thinking about for awhile, and discussed with a few other http server people before. I think that for the 'stable' branch, we should move to time based releases. My proposal is for every 2 months, we do a release of the main stable branch, which at this time is 2.2.x. Security Issues of great importance of course would trigger an immediate release. Depending on the nearness to a scheduled release, we may or may not scrap the next time based release. I guess I am not sure what setting a schedule is trying to accomplish. Can't you do this already? If somebody wants to release every 2 months, that person can call for the release and be the RM every two months. In other words, as long as there is somebody willing to do the work, then the work will happen. If a release isn't required, ie. no real appreciable improvement since the previous release, then why require everyone to mobilize for very little gain. I guess I am looking for the problem that a hard schedule resolves when we can already release as early or as often as desired. Brad
Re: AuthzMergeRules directive
On 4/14/2008 at 12:21 PM, in message [EMAIL PROTECTED], Chris Darroch [EMAIL PROTECTED] wrote: Brad Nicholes wrote: I'm not real excited about adding a new authz directive. Authn and authz are already very complex and adding a new directive to the mix will just help to confuse people even more. That's a good point. Mostly the idea of an Accept replacement for Require came up as a way to distinguish pre-2.4 and 2.4 per-dir authz, and in case there were any Require foo directives which had slightly different meanings in the two contexts and which might therefore trip people up. If we can do without it, all the better. I am OK with this one except for the reason that I mentioned before. By allowing authz to be inherited even when AuthzMergeRules is OFF is kind of a conflict. In other words, since AuthzMergeRules OFF implies an AND, 1 AND 0 should be 0 or no authz rather than inherited authz. However I could buy into this if it seems to make more intuitive sense to the user. Well, I may be missing something, but what I envisioned was that AuthzMergeRules had three options: Off (i.e., inherited until overridden, the pre-2.4 default), SatisfyOne, and SatisfyAll. That would give administrators full control over how they wanted authz in different per-dir blocks to be merged. It seems to me we have three basic possibilities when it comes to merging authz across per-dir blocks, and the most common authz case to consider is going to be where security gets tighter as you move down the document tree. Imagine something like the following in a pre-2.4 configuration, where admin is not a member of team: Directory /htdocs ## full access /Directory Directory /htdocs/team ## anyone in team has access Require group team /Directory Directory /htdocs/team/admin ## only admin user has access Require user admin /Directory 1) The first option for 2.4 merging is to use OR logic (the current default in trunk). This leads to anyone in team having access to /htdocs/team/admin, I believe. I think I'd have to vote -1 against this, because it will lead to lots of previously secure configurations becoming insecure. Plus it would seem to increase the required number of directives (since you have to add AuthzMergeRules Off in each sub-Directory) to achieve what seems to me to be a typical configuration, i.e., increasing security as you go down the tree. 2) Another option might be to use AND logic. In this case, if I'm applying the logic correctly, no one would be able to access /htdocs/team/admin given the configuration above in a 2.4 context (since admin isn't in team). While more secure, this also seems counter-intuitive to me. Maybe -0.5? 3) Finally there's the pre-2.4 logic of overriding all previous authz. This would seem to be the most preferable option, since it ensures many pre-2.4 configurations will continue to work as expected, and I think also reduces configuration verbosity in typical cases. You were concerned, I think, about more complex configurations like this: Directory /www/pages SatisfyAll Require ip 10.10.0.1 Require ldap-group sales SatisfyOne Require ldap-group ne-sales Require ldap-group sw-sales /SatisfyOne /SatisfyAll /Directory Directory /www/pages/private Require ldap-group marketing /Directory I would suggest that the default pre-2.4 logic of overriding previous authz when any authz is defined in a per-dir block is still reasonable as a default. Thus, only those in marketing have access to /www/pages/private, and they can access it from other addresses than 10.10.0.1. Even if this isn't what is desired, it's clear enough that an administrator can figure out what's going on and why the configuration isn't achieving the desired result. I'm OK with it up to this point. I'd propose giving the administrator the choice of both alternatives to the default logic. Instead of simply offering AuthzMergeRules On, there would be two alternatives to the default Off condition. These would be AuthzMergeRules SatisfyOne (the OR logic) and AuthzMergeRules SatisfyAll (the AND logic). We might offer Or and And as synonyms for SatisfyOne and SatisfyAll, respectively. This is where it starts to go wrong for me. Where it gets confusing for somebody who is trying to figure out what the configuration is doing is: Directory /www/pages SatisfyAll Require ip 10.10.0.1 Require ldap-group sales SatisfyOne Require ldap-group ne-sales Require ldap-group sw-sales /SatisfyOne /SatisfyAll /Directory Directory /www/pages/private AuthzMergeRules SatisfyOne SatisfyAll Require ldap-group marketing Require ldap-group alt-marketing /SatisfyAll /Directory Now I have to reconcile the logic
Re: svn commit: r646582 - /httpd/httpd/trunk/modules/ldap/util_ldap.c
On 4/10/2008 at 12:12 AM, in message [EMAIL PROTECTED], Ruediger Pluem [EMAIL PROTECTED] wrote: On 10.04.2008 00:49, [EMAIL PROTECTED] wrote: Author: bnicholes Date: Wed Apr 9 15:49:31 2008 New Revision: 646582 URL: http://svn.apache.org/viewvc?rev=646582view=rev Log: Move the initialization of rebind to the post_config handler so that it is done during the actual module load stage rather than the preload stage. If done during the preload stage, the pool passed into the initialization function will be cleared and all allocations will be freed. But isn't it the pconf pool in both cases? Currently I cannot follow this argument. Mind to explain in more detail? Regards Rüdiger What is happening is that when httpd is invoked, the first thing it does is preload all of the modules to make sure that everything works. The preload of the modules also calls the util_ldap_create_config() which subsequently calls apr_ldap_rebind_init(). In apr_ldap_rebind_init() some allocations are done. Actually a thread mutex is created against the pool that was passed in. In addition, the clean up of the mutex was tied to the pool and the rebind init function also assigned to a global static variable, the mutex handle. Then when the preload stage is complete, it clears the memory pool which also causes the mutex to be destroy. However the mutex handle, which is now bogus, is still assigned to the global static variable. Finally the real module loading stage occurs and util_ldap_create_config() and apr_ldap_rebind_init() are called again. Only this time the apr_ldap_rebind_init() sees that the mutex global static variable is no longer NULL so it doesn't bother to recreate the mutex leaving a bogus value in the static variable. When an ldap authentication occurs later and tries to use the bogus mutex handle, at least on NetWare, the code segfaults. The change was simply moving the init of the rebind functionality to a location in the code where everything else is initialized and is also protected so that the initialization only happens during the real module load stage rather than the preload stage. Brad
Re: AuthzMergeRules directive
On 4/9/2008 at 11:08 AM, in message [EMAIL PROTECTED], Chris Darroch [EMAIL PROTECTED] wrote: Chris Darroch wrote: Here's another thought: for people doing mass virtual hosting, and who let their customers put authn/z directives into .htaccess files with AllowOverride AuthConfig, I would think it may be important to ensure that these rules still merge together in the way they used to. Otherwise upgrading to 2.4 might mean tracking down every .htaccess file and rewriting it to do the right thing (sticking in an AuthzMergeRules Off or something). For some people doing vhosting I suspect that would be a tall order, so it would be good if 2.4 would function securely in this situation, by default. That said, I don't use .htaccess files and may not be making any sense today; my apologies. Here's a follow-up notion; admittedly, it represents a lot of re-refactoring work. It would provide an secure upgrade path for people with complex configurations, including those with many legacy .htaccess files to consider. A new directive, Accept, is introduced to take the place of Require. It functions as Require does now in 2.4. Thus we have two groups of authz directives, old (Require/Satisfy/Order/ Deny/Allow) and new (Accept/Reject/SatisfyOne/SatisfyAll). The old directives function as they did in 2.2. Authz directives would be parsed and merged as follows: I'm not real excited about adding a new authz directive. Authn and authz are already very complex and adding a new directive to the mix will just help to confuse people even more. Especially when they can't tell the difference between 'require' and 'accept' or when they should use one or the other. The requirement to stay somewhat backwards compatible in all of this stuff lends to the confusion already. 1) Within a per-dir config block (Location/Directory/etc.) old and new authz directives may not be mixed. If directives from both groups appear, a config-time error is thrown. 2) When merging new authz directives within a per-dir config block, the default merge rule is OR, as in 2.4 at present. This is equivalent to using a SatisfyOne around all new authz directives within a per-dir config block. 3) When merging per-dir config blocks at runtime, the following rules are applied; we'll call the parent block base and the child block new: 3.1) If the new block contains no authz directives, the base's authz configuration is inherited (if any). This follows current 2.2 behaviour. I am OK with this one except for the reason that I mentioned before. By allowing authz to be inherited even when AuthzMergeRules is OFF is kind of a conflict. In other words, since AuthzMergeRules OFF implies an AND, 1 AND 0 should be 0 or no authz rather than inherited authz. However I could buy into this if it seems to make more intuitive sense to the user. 3.2) If the new block contains old authz directives, the base block's authz configuration is discarded, and the new block's authz directives are applied to a clean slate. This follows current 2.2 behaviour. 3.3) If the new block contains new authz directives, the base and new blocks' authz configurations are merged using the rule specified by AuthzMergeRules (as it appears within the new block): This is where things get a little confusing for me. I'm not really too excited about authz logic behavior changing just because of which version of an authz directive you used. This type of change in behavior isn't intuitive. At least with the way it is now,the behavior change would be between 2.2 and 2.4 rather than two different behaviors in 2.4 itself. 3.3.1) If AuthzMergeRules is set to Off or is not defined, the base block's authz configuration is discarded, and the new block's authz directives are applied to a clean slate. This follows current 2.2 behaviour, to avoid confusion and simplify most configurations. 3.3.2) If AuthzMergeRules is set to Or or SatisfyOne, the base block's authz configuration is merged with the new block's as if they were collectively contained within a SatisfyOne block. 3.3.3) If AuthzMergeRules is set to And or SatisfyAll, the base block's authz configuration is merged with the new block's as if they were collectively contained within a SatisfyAll block. This could be OK however I'm not real comfortable with specifying the merging logic in two different ways. In other words, if AuthzMergeRules is set to OR yet SatisfyAll is also specified in the same block. The new authz directives may take a little getting used to when first used, but at least there is a consistent way to do things and a behavior that will be consistent in 2.4 without having to worry a lot about what ifs. Writing that all out it mostly just
Re: svn commit: r646582 - /httpd/httpd/trunk/modules/ldap/util_ldap.c
On 4/10/2008 at 2:00 PM, in message [EMAIL PROTECTED],
Ruediger
Pluem [EMAIL PROTECTED] wrote:
On 10.04.2008 18:11, Brad Nicholes wrote:
On 4/10/2008 at 12:12 AM, in message
[EMAIL PROTECTED],
Ruediger
Pluem [EMAIL PROTECTED] wrote:
On 10.04.2008 00:49, [EMAIL PROTECTED] wrote:
Author: bnicholes Date: Wed Apr 9 15:49:31 2008 New Revision:
646582
URL: http://svn.apache.org/viewvc?rev=646582view=rev Log: Move
the
initialization of rebind to the post_config handler so that it is
done
during
the actual module load stage rather than the preload stage. If
done
during
the preload stage, the pool passed into the initialization
function
will be
cleared and all allocations will be freed.
But isn't it the pconf pool in both cases? Currently I cannot
follow
this
argument. Mind to explain in more detail?
Regards
Rüdiger
What is happening is that when httpd is invoked, the first thing it
does is preload all of the modules to make sure that everything
works.
The preload of the modules also calls the util_ldap_create_config()
which subsequently calls apr_ldap_rebind_init(). In
apr_ldap_rebind_init() some allocations are done. Actually a
thread
mutex is created against the pool that was passed in. In addition,
the
clean up of the mutex was tied to the pool and the rebind init
function
also assigned to a global static variable, the mutex handle. Then
when
the preload stage is complete, it clears the memory pool which also
causes the mutex to be destroy. However the mutex handle, which is
now
bogus, is still assigned to the global static variable. Finally
the
real module loading stage occurs and util_ldap_create_config() and
apr_ldap_rebind_init() are called again. Only this time the
apr_ldap_rebind_init() sees that the mutex global static variable is
no
longer NULL so it doesn't bother to recreate the mutex leaving a
bogus
value in the static variable. When an ldap authentication occurs
later
and tries to use the bogus mutex handle, at least on NetWare, the
code
segfaults.
The change was simply moving the init of the rebind functionality to
a
location in the code where everything else is initialized and is
also
protected so that the initialization only happens during the real
module
load stage rather than the preload stage.
Thanks for explaining. I now understand why it is bad to call
apr_ldap_rebind_init twice, but I still do not get how your change
helps
avoiding this as the post_config hook is also called twice and the
pconf
pool that is used for apr_ldap_rebind_init is cleaned up in between.
Sorry for being persistent on this, but care to explain where my
thoughts
are wrong here?
In other parts of the code these situations are normally solved by
something
like if (staticvar++) {} with staticvar being an static global int
initialized
with 0.
It is protected by the code at the beginning of util_ldap_post_config()
that calls apr_pool_userdata_get() and checks a user data tag. If the
tag is empty then this is the first time that the function was called.
It then puts something in the tag and returns. The next time it reads
the user data tag, it finds what it put there the first time. Now it
knows that this is the second time and goes ahead with initializations.
This is actually the preferred way to do it rather than using a static
variable. Static global variables only work on platforms that have
process separation for data areas. NetWare *isn't* one of those
platforms. A global variable is global to everything running on the
box. That was why I had to make the other NetWare specific changes in
ldap_rebind.c. Static globals are bad. :(
Brad
Re: AuthzMergeRules directive
On 4/8/2008 at 10:41 AM, in message [EMAIL PROTECTED], Chris
Darroch [EMAIL PROTECTED] wrote:
Brad Nicholes wrote:
Directory /www/pages
Reject ip 127.0.0.1//Or any other Require directive
/Directory
Directory /www/pages/whatever
...
/Directory
Since the /www/pages/whatever directory did not specify any authz,
what should happen? If the AuthzMergeRules is OFF then what is the
authz for /www/pages/whatever? I'm not sure that 'all granted' is
correct but then neither is 'all denied'. Since the AuthzMergeRules
is OFF then merging the authz would be counter intuitive.
If AuthzMergeRules is ON then 127.0.0.1 is rejected and all
others are allowed. I guess the thinking was that leaving the
default ON would leave fewer unknowns however in some instances may
not be as intuitive.
Well, again referring to my intuition based on configuring 2.2
and prior servers, I would expect the /www/pages authz to cover
everything under /www/pages (including /www/pages/whatever) unless
I define other authz rules -- at which point, the corresponding authz
slate is wiped clean for that subdirectory, and my local authz
directives take effect. (Not all authz directives, mind you, just
those which I'm overriding.)
So I can do something like:
Directory /www/pages
Require valid-user
/Directory
Directory /www/pages/images
## still protected
Dav filesystem
/Directory
Directory /www/pages/private
Require user admin
/Directory
One key to this behaviour, IIRC, is that all of the stock authz
modules in 2.2 use the default merge_dir_config rules; that is,
none of them define their own merge function and all just say:
NULL, /* dir merger --- default is to override */
Then the ap_merge_per_dir_configs() logic which gets applied
when merging their per-directory configurations is to cause the
ancestor's configuration to be inherited, unless there's a new
per-directory configuration for the same module.
The Require directive is, again IIRC, handled in the core
per-directory configuration, and the logic in merge_core_dir_configs()
is similar: duplicate the ancestor's configuration, and then
override the inherited Require directives if there's a Require
directive in the new per-directory configuration:
if (new-ap_requires) {
conf-ap_requires = new-ap_requires;
}
So I think the result is that each authz directive gets inherited
down through the directory configurations, until something overrides
it, at which point everything to do with that directive is started
fresh. It's a relatively space-efficient configuration style,
actually, because you only need to put in an authz directive if you're
changing something from what's inherited.
I hope I've described the existing situation accurately; at any rate,
it seems to me to be a good way to structure the 2.4 authz merge rules.
It would mean you mostly didn't need to specify AuthzMergeRules (saves
typing and errors) and things are protected down through the directory
hierarchy by default (also good) unless you specifically include a
new authz directive, at which point that takes effect and is inherited
downwards. So the default merge logic would be, I guess, neither AND
nor OR but inherit-until-overridden.
Chris.
Your assumptions about how the 2.2 per-dir merging is correct. Unfortunately
the same concepts no longer apply to 2.4. The reason why is this:
Directory /www/pages
SatisfyAll
Require ip 10.10.0.1
Require ldap-group sales
SatisfyOne
Require ldap-group ne-sales
Require ldap-group sw-sales
/SatisfyOne
/SatisfyAll
/Directory
Directory /www/pages/images
## still protected
Dav filesystem
/Directory
Directory /www/pages/private
Require ldap-group marketing
/Directory
Which ldap-group is overridden vs merged? Since the 2.2 authz had no concept
of logic and was simply a list of require statements, it was very easy to add
to the list or override an entry in the list. This is no longer the case. The
require statements have to be merged according to some type of logic rules.
Your suggestion would work if /www/pages/private simply reset and applied only
the require statements it found in its own directory block (ie. AuthzMergeRules
OFF), but picking the inherited logic apart and trying to rework it, won't
really work.
BTW, one of the main reasons why the logic operators were added to authz was to
solve the problem that existed in 2.2. The problem was that if multiple
require statements appeared in a single directory block or in a hierarchy, you
never really knew in which order they were actually applied. Basically it came
down to the order in which the authz modules happen to have been loaded. By
applying the authz through logical operators, it replaced the simple array of
entries with a logic tree, which is why the API ap_requires
Re: AuthzMergeRules directive
On 4/4/2008 at 4:33 PM, in message [EMAIL PROTECTED], Chris Darroch [EMAIL PROTECTED] wrote: Brad Nicholes wrote: So here was the thinking behind it when AuthzMergeRules was introduced. Maybe there is still a bug here that needs to be addressed. http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/%3c44C4E0FA.8060 [EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/%3c44CA3C33.6720 [EMAIL PROTECTED] I'm not sure it's a bug per se, but rather, an unexpected break from the intuition developed by administrators used to configuring 2.2.x and prior versions about how authorization cascades through configuration blocks. I may be wrong about this, but here's how I'd expect the example from your second thread to work. The example is: Directory /www/pages Reject ip 127.0.0.1 /Directory Directory /www/pages/secure Authtype Basic ... SatisfyAll Require valid-user Reject user joe /SatisfyAll /Directory My hunch is that prior to 2.2, the fundamental logic when merging authz rules across blocks was neither AND nor OR, but reset. That is, it relies on the configuration walks to find the authz directives in the most closely relevant block. Those directives are then applied; what appeared in less relevant blocks is ignored. I haven't looked closely at the logic, but that's what seems to happen if you've got something like: Directory /htdocs Require valid-user /Directory Directory /htdocs/admin Require user admin /Directory So in your example, my configuration intuition suggest that only what appears in the Directory /www/pages/secure block applies to anything under /www/pages/secure, and that the Reject ip 127.0.0.1 would just not applied at all to these URIs. So I'd expect that to access /www/pages/secure I'd need to be any valid user except joe; whether I was connecting from 127.0.0.1 wouldn't matter. Now, within a block, having OR be the default merge logic would seem to make sense; if you want AND, you need SatisfyAll. So: Directory /www/pages/secure Require user betty Require user joe /Directory means betty and joe alone have access, regardless of what applied to /www/pages. But if the following is also configured, then a reset rule across blocks would mean that it does what one expects; betty and joe would be rejected along with everyone else when attempting to access URIs under /www/pages/secure/really. Directory /www/pages/secure/really Require all denied /Directory This would presumably work identically: Directory /www/pages/secure/really Reject all granted /Directory Anyway, that's a bit of a shot in the dark. Hope it helps. Thanks, Chris. So I believe that the behavior that you have described could be accomplished by just switching the default of AuthzMergeRules from ON to OFF. The only case that I am still worried about is the following: Directory /www/pages Reject ip 127.0.0.1//Or any other Require directive /Directory Directory /www/pages/whatever ... /Directory Since the /www/pages/whatever directory did not specify any authz, what should happen? If the AuthzMergeRules is OFF then what is the authz for /www/pages/whatever? I'm not sure that 'all granted' is correct but then neither is 'all denied'. Since the AuthzMergeRules is OFF then merging the authz would be counter intuitive. If AuthzMergeRules is ON then 127.0.0.1 is rejected and all others are allowed. I guess the thinking was that leaving the default ON would leave fewer unknowns however in some instances may not be as intuitive. Brad
Re: AuthzMergeRules directive
On 4/4/2008 at 5:43 PM, in message [EMAIL PROTECTED], Paul J. Reder [EMAIL PROTECTED] wrote: Perhaps it would make more sense to provide this as an explicit value rather than On vs. Off and set the default to the previous behavior. Perhaps something like: AuthzMergeRules [AND | OR | OVERRIDE] with default being OVERRIDE (if I grok correctly) Meaning that any directives specified at only one level would be merged to lower levels, but the merge behavior of directives specified at multiple levels would be controlled by this directive (i.e. ANDed, ORed, or OVERRIDEn with levels above it). This could result in complex logic if subsequent levels of containers mixed AND, OR, and OVERRIDE, but if it was designed to be explicit then the user would have specific control over each authbit along the way. When I originally looked at the implementation of the authzMergeRules directive, the above suggestion was my first thought. However I think I decided not to go this route simply because the same thing could be accomplished in a less complex way by making the user explicitly decide the merging rules within the configuration of the directory block itself. In other words, if they wanted OR merging between a higher level and a lower level block, then do nothing or specify SatisfyOne in the lower level block. If they wanted AND merging then specify SatisfyAll in the lower level block. This follows the same concepts as would be done within a single directory block. This avoids having to resolve logic conflicts and precedents between two different directives, AuthzMergeRules and SatisfyXXX Brad
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamicconfiguration for the hackathon?])
On 4/4/2008 at 1:20 AM, in message [EMAIL PROTECTED], William A. Rowe, Jr. [EMAIL PROTECTED] wrote: 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? I won't be there, but you could use the tail end of my auth architecture slides that talk about the authz refactor. http://people.apache.org/~bnicholes/presentations/ApacheconUS2007_autharch.ppt Brad
AuthzMergeRules directive (was:Re: 2.4)
On 4/4/2008 at 11:37 AM, in message [EMAIL PROTECTED], Chris Darroch [EMAIL PROTECTED] wrote: 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? So here was the thinking behind it when AuthzMergeRules was introduced. Maybe there is still a bug here that needs to be addressed. http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/[EMAIL PROTECTED] Brad
2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
On 4/3/2008 at 8:06 AM, in message [EMAIL PROTECTED], Jim Jagielski [EMAIL PROTECTED] wrote: 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 :) Please let's get 2.4 out. It would be great to finally have the new Authz configuration logic see the light of day along with other functionality that has been sitting around for a while. Brad
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: svn commit: r614605 - in /httpd/httpd/trunk: include/util_ldap.h modules/ldap/util_ldap.c
On 1/23/2008 at 7:25 PM, in message [EMAIL PROTECTED], Paul J.
Reder [EMAIL PROTECTED] wrote:
Ruediger Pluem wrote:
On 01/23/2008 07:14 PM, [EMAIL PROTECTED] wrote:
Author: rederpj
Date: Wed Jan 23 10:14:41 2008
New Revision: 614605
URL: http://svn.apache.org/viewvc?rev=614605view=rev
Log:
This adds Apache support (taking advantage of the new APR capability)
for ldap rebind callback while chasing referrals. This allows direct
searches on LDAP servers (in particular MS Active Directory 2003+)
using referrals without the use of the global catalog.
This addresses PRs 26538, 40268, and 42557
@@ -2614,6 +2710,15 @@
Specify the LDAP socket connection timeout in seconds
(default: 10)),
+AP_INIT_FLAG(LDAPReferrals, util_ldap_set_chase_referrals,
+ NULL, OR_AUTHCFG,
+ Choose whether referrals are chased ['ON'|'OFF'].
Default ON'),
+
+AP_INIT_TAKE1(LDAPReferralHopLimit,
util_ldap_set_referral_hop_limit,
+ NULL, OR_AUTHCFG,
+ Limit the number of referral hops that LDAP can
follow.
+ (Integer value, default=5)),
+
{NULL}
};
@@ -2638,7 +2743,7 @@
module AP_MODULE_DECLARE_DATA ldap_module = {
STANDARD20_MODULE_STUFF,
- NULL,/* create dir config */
+ util_ldap_create_dir_config, /* create dir config */
NULL,/* merge dir config */
Why no merge dir config? How do you inherit your settings in this case?
Now that you ask that question it makes me realize that the better question
is
probably Should the directives be directory scoped or server scoped? The
rest
of the util_ldap directives are all server scoped. Is there any compelling
reason
that the referral directives would need to be alterable on a
directory-by-directory
(or htaccess) basis or should it be turned on/off and limited on a
server-wide scope?
I wish I had a better memory, but I vaguely recall going down this path once
before between server-merge and dir-merge (mailing list archives might remember
better than I do) . I know that when it comes to anything SSL related, not all
LDAP SDKs can handle per-directory options. Novell LDAP SDK being one of them.
So when it comes to setting options on a per-directory basis, it might get a
little tricky depending on the LDAP SDK that is being used.
Brad
Re: [VOTE] Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8
On 1/11/2008 at 7:09 AM, in message [EMAIL PROTECTED], Jim Jagielski [EMAIL PROTECTED] wrote: I am calling for a release VOTE on the above releases of Apache HTTP Server (1.3.41, 2.0.63 and 2.2.8). Pre-release tarballs of Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8 are available for download and test at: http://httpd.apache.org/dev/dist/ Their availability does not constitute an official release. Voting will close in 72 hours (~9am, eastern, on Monday Jan. 14th) +1 1.3.41, 2.0.63, 2.2.8 NetWare
Re: httpd trunk - How to get info that ap_requires used to return
On 1/7/2008 at 4:56 AM, in message
[EMAIL PROTECTED], Rolf Banting
[EMAIL PROTECTED] wrote:
My immediate aim is to test Isaac's UDP support patch with mod_perl - I
want to make a case for apache as a viable alternative for our service
platform and udp support is essential. If I can get the mod_perl test suite
to pass I increase the credibility of my proposal.
The mod_perl tests that use ap_requires are quite simple - the Require
lines are retrieved via ap_requires and then the values compared against
data in the current request. Example:
In the conf:
Require user goo bar
Require group bar tar
In the test code:
# extract just the requirement entries
my %require =
map { my ($k, $v) = split /\s+/, $_-{requirement}, 2; ($k, $v||'') }
@{ $r-requires };
debug \%require;
return Apache2::Const::SERVER_ERROR unless $require{user} eq $users;
return Apache2::Const::SERVER_ERROR unless $require{group} eq $groups;
$require{user} should be 'goo bar'
$require{group} should be 'bar tar'
I don't yet have much detailed knowledge of the httpd code - my naive
interpretation is that ap_requires returned a list of require_line structs
where the 'requirement' field is
everything after the 'Require' in the config line. If there was some
way to get a list of the Require statements in the conf file it would
be an easy matter to re-jig the test code.
I suppose I could parse the config file directly (e.g. with Config::General
)
to get the Require lines - but I would prefer to use any in-built httpd
support if possible.
From my naive perspective I'd offer that per-directory queries for
configuration
information such as all Require statements are useful things to have.
The problem is that the Require statements are no longer stored as a list of
require_line structs so retrieving them as such isn't possible. The Require
statements are added to a logic tree as they are read from the configuration
and then whenever authorization is done for that Directory, the logic tree is
traversed and a result is returned. Obviously if there is only a single
Require statement in the Directory, the logic tree would be very simple, but
this isn't something that you can count on. The authorization logic could be
anything. As far as the configuration file is concerned, it could look like
anything from
Require User goo bar
Require Group bar tar
which would be interpreted as:
if (User == 'goo') || (User == 'bar') || (Group == 'bar') || (Group == 'tar')
then
allow
else
deny
to:
Require User goo
SatisfyAll
Require Group foo
SatisfyOne
Require User bar
Require Group tar
/SatisfyOne
/SatisfyAll
which is interpreted as:
If (user == 'goo') || (group == 'foo' (User == 'bar' || Group == 'tar'))
then
Allow
else
Deny
It appears that your test script doesn't really care about the authorization
result but rather if a Require statement simply exists with a given value. At
this point there isn't a way to get that information through an API. I guess
an API could be added that given a specific value would traverse the logic tree
to validate that a matching Require statement exists. But outside of the Perl
test, I'm not sure what usefulness an API like that would have.
Brad
Re: httpd trunk - How to get info that ap_requires used to return
On 1/4/2008 at 10:12 AM, in message [EMAIL PROTECTED], Rolf Banting [EMAIL PROTECTED] wrote: Folks, I want to build mod_perl 2 against httpd trunk but I've encountered a few road-blocks. The one that has held me up recently is to do with the removal of ap_requires from the httpd source sometime since httpd 2.2.6. The mod_perl test suite includes several tests that rely on ap_requires to dig out Require data e.g Require user shaun Require group sheep These obviously now fail when mp is built against the httpd trunk. Presumably there are other straightforward ways to get at the Require configuration for a given directory? I have had a scout round - the mod_authz code uses the require_line data structure but I can't immediately see how this can be related to mod_perl. Thanks, Rolf Well, I'm not sure you are going to like the answer. The authz functionality has been completely rearchitected in httpd trunk. Rather than being hooked based which required every authz module in the chain to evaluate all of the require statements, it is now provider based. Basically what this means is that an authz module simply registers the authz types that it supports and then the provider for that authz type is only called when needed. In addition to being provider based, a new logic concept has been added to allow the user to combine different authz types using simple logic groupings. In this architecture, the functionality that ap_requires() performed, no longer makes. The 'Require' statement(s) within a Directory block is no longer just a single authz type or list of types, the authz result must be evaluated within the logical context in which it exists. Under the old architecture, ap_requires() returned a simply list of authz types. In the new architecture, the authz types that are included in a Directory block are no longer a list, but rather a logic tree. Since I don't know how the perl test suite works, I couldn't really tell you how the suite must be rearchitected to fit the new model. I vaguely remember having this discussion with somebody a year or more ago. You might want to check the list archive. Other than that, we would just have to discuss what the test suite is doing and how it might be reworked. Brad
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 1/4/2008 at 1:00 PM, in message [EMAIL PROTECTED], Jim Jagielski [EMAIL PROTECTED] wrote: Apache HTTP Server fans, The latest versions of all 3 variants of Apache HTTP Server (1.3.40, 2.0.62 and 2.2.7) have been tagged. The test tarballs are available for testing and feedback at the below location. Everyone is reminded that this does not constitute an official release of these tarballs yet; assuming these pass muster, the hope and intent is to release and announce early next week. All files in: http://httpd.apache.org/dev/dist/ All 3 are looking good on NetWare Brad
Re: mod_ldap: server_config structure part of the API?
On Thu, Nov 15, 2007 at 2:33 PM, in message [EMAIL PROTECTED], Eric Covener [EMAIL PROTECTED] wrote: All, mod_ldap has it's own server_config struct defined in httpd/include/util_ldap.c -- does this location implicitly make the server config structure part of the API? If So, what kind of one-time bump would it take to pull this out of the public header? It would have to be a 2.4 change. I don't think that you could get away with making this type of change in 2.2. util_ldap_state_t isn't being used by httpd outside of util_ldap, but that doesn't mean it's not being referenced by somebody (although it shouldn't be). Brad
Re: As we contemplate what to fix, and how to roll out 2.4 and 3.0
On 10/1/2007 at 4:52 PM, in message [EMAIL PROTECTED], William A. Rowe, Jr. [EMAIL PROTECTED] wrote: William A. Rowe, Jr. wrote: Give that some thought :) One thing I'm pondering is a 2.3.0 alpha in the near future. If only to give the we stay back at version n.x-1 crowd something to chew on. Not to mention that it would be good for folks to start exploring what needs to be fixed in the API, etc. +1, It's been almost 2 years since the new provider based authorization code was added to 2.3. I would really like to see how it stands up. Brad
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
On 9/4/2007 at 3:29 PM, in message [EMAIL PROTECTED], Jim Jagielski [EMAIL PROTECTED] wrote: Available for your testing pleasure, 3, count 'em, 3 Apache HTTP Server release candidate tarballs, located, as expected at: http://httpd.apache.org/dev/dist/ This vote will run through Sept 6, 2007 and close Sept 7, unless otherwise noted... +/-1 (x == +1) [ ]apache_1.3.39 [ ]httpd-2.0.61 [ ]httpd-2.2.6 Thanks!! +1 all Netware Brad
Re: authnz_ldap in 2.2.x
On 8/29/2007 at 7:51 PM, in message
[EMAIL PROTECTED], Eric Covener
[EMAIL PROTECTED] wrote:
In 2.2.x If authz_XXX are one of dbm, owner, or groupfile they track
the list of requires and decline if they don't see any they're
responsible for -- this isn't a crap shoot of module ordering in this
case.
$ grep \!required *.c
mod_authz_dbm.c:if (!required_group || !conf-authoritative) {
mod_authz_groupfile.c:if (!required_group || !conf-authoritative) {
mod_authz_owner.c:if (!required_owner || !conf-authoritative) {
mod_authz_user.c:if (!required_user) {
That roughly leaves authz_host, authz_default, and authnz_ldap.
authz_host has a built-in default based on Order, and authz_default
doesn't have any Requires to check -- leaving authnz_ldap as the odd
man out.
True, so that brings up the question of what does AuthzXXXAuthoritative really
mean? Does it mean that if set to ON, this module is authoritatively
responsible for authorization and if it can't (whatever the reason including no
require statement), then authorization fails? Or does it mean that the module
is only authoritatively responsible for authorization if a matching require
statement exists? According to what you are saying as well as what the code is
currently saying in the other authz modules, the latter is true. And if that
is really the definition of AuthzXXXAuthoritative, then it appears that
authnz_ldap needs to be fixed.
Brad
Re: authnz_ldap in 2.2.x
On 8/29/2007 at 8:28 AM, in message [EMAIL PROTECTED], Eric Covener [EMAIL PROTECTED] wrote: mod_authnz_ldap in 2.2.x doesn't track whether or not it has seen any applicable 'Require ldap-*' entries in the requires list, and also doesn't explicitly accept valid-user (despite a commnt) Other authz modules check that their flavor of Require was present where they check if they're configured to be authoritative. At the simplest level, this allows the authz modules to DECLINE and let authz_user authorize based on Require valid-user To do authn-only where LDAP is used as the basic provider, (or otherwise configured in that context) you have to make LDAP non-authoritative or come up with some LDAP filter or attribute that is always true. Is this something were stuck with in a stable release? The trunk authz provider API makes this relevant only to 2.2.x. Yes, the idea, even going forward into 2.3, is to not have overlapping authz types. It doesn't really make sense to have all of the various authz modules replicate valid-user. There should only be one authz module that implements an authorization type. That is why you only see authz_user implement user where authnz_ldap implements ldap-user. They both authorize users in different ways. In 2.0 if both mod_auth and mod_auth_ldap were both loaded (for whatever reason), they both implemented user. So when your configuration used require user, you never really knew which one you were getting. The only real reason why you have to set LDAP to non-authoritative when using LDAP authn only, is because LDAP had to combine both authn and authz into the same module. This is not a good practice in general, but in the case of LDAP there was so much code and data overlap between authn_ldap and authz_ldap, that splitting them apart was a problem. Brad
Re: authnz_ldap in 2.2.x
On 8/29/2007 at 3:14 PM, in message [EMAIL PROTECTED], Eric Covener [EMAIL PROTECTED] wrote: On 8/29/07, Brad Nicholes [EMAIL PROTECTED] wrote: The only real reason why you have to set LDAP to non-authoritative when using LDAP authn only, is because LDAP had to combine both authn and authz into the same module. This is not a good practice in general, but in the case of LDAP there was so much code and data overlap between authn_ldap and authz_ldap, that splitting them apart was a problem. To clarify; I understand not duplicating valid-user, but the other authz modules know to decline when they haven't seen a single requirement they grok, which allows mod_authz_user to authorize the request in the case of Require valid-user. I don't think the coupling is a factor there. No, all of the authz modules should be working the same. They all have an AuthzXXXAuthoritative directive which defaults to ON. The problem with 2.0 and 2.2 is that if you load multiple authz modules and try to use multiple require statements, you have no guarantee as to which authz handler will get called first. So it might look like authz_XXX module is DECLINEing and allowing authz_user's Require valid-user to handle the authorization, when in fact the authz_XXX handler was never called at all. This problem has been taken care of in 2.3. The difference between mod_authnz_ldap and other authz modules is that in most cases, an Authz module is not loaded unless it is needed. In the case of Authnz_LDAP, you don't have that option. If you load Authnz_LDAP, you get both authn and authz even if you don't want to use the authz side. So your only choice is to disable it by setting the AuthzLDAPAuthoritative to OFF. Brad
Re: svn commit: r563196 - /httpd/httpd/branches/2.2.x/STATUS
On 8/6/2007 at 12:28 PM, in message [EMAIL PROTECTED], Justin Erenkrantz [EMAIL PROTECTED] wrote: On 8/6/07, Jim Jagielski [EMAIL PROTECTED] wrote: Ummm... These didn't have 3 +1 votes. So why were they applied and committed?? I think for platform-specific code we've been okay with a smaller consensus than 3. If our only two NetWare guys agree on the change, then I doubt the rest of us have anything to add to the conversation. And until recently, we only had one NetWare-savvy committer; so we're making progress towards getting 3. =P -- justin Not to stir the pot or anything, just to add some context, until recently when we gave faunkg commit rights on the httpd and apr projects, I was the only NetWare maintainer. As such, you never really saw any NetWare backports hit the status file because I just commited them. Yes, the patches flowed through trunk first, but nobody really noticed because nobody really cared, other than me. If I had proposed the backports, I would have never achieved 3 +1's on anything. Now that we have another NetWare person, I feel that NetWare backports should be seen in the status file and voted on within a reasonable time period (lazy concensus, so to speak). This is what I instructed faunkg to do with the NetWare patches that he wanted to backport to 2.2. But even in this situation there are now only two of us, so at best a NetWare backport will only get 2 +1's and with my time for doing reviews or anything else related to Apache, becoming more limited, even that is stretching it. I think that there are sometimes when lazy consensus needs to override strict RTC. NetWare is one of them. So for now like Justin said, at least 2 +1's is better than nothing. :) Just my thinking, Brad
Re: svn commit: r534533 - in /httpd/httpd/trunk: include/http_core.h modules/aaa/mod_access_compat.c modules/aaa/mod_auth.h modules/aaa/mod_authz_core.c modules/aaa/mod_authz_default.c server/core.c
On 5/2/2007 at 11:47 AM, in message [EMAIL PROTECTED], Joshua Slive [EMAIL PROTECTED] wrote: On 5/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: bnicholes Date: Wed May 2 09:31:39 2007 New Revision: 534533 URL: http://svn.apache.org/viewvc?view=revrev=534533 Log: re-introduce ap_satisfies API back into core and modify how the access_checker, check_user_id and auth_checker hooks are called so that they respect the precedence that is set through the satisfy ALL/ANY directive. This also restores the directives order, allow, deny, satisfyas supported directives rather than being deprecated. These directives still remain in mod_access_compat however. Fine. But then let's just revert mod_authz_host to the 2.2 version and delete mod_access_compat. (Or, in other words, rename mod_access_compat to mod_authz_host.) I don't see the reason for having two supported ways of doing the same thing. Joshua. Yeah, that's where I mentioned that things might look a little confusing. There actually is a good reason to have both and yes some of the functionality can overlap. The reason for having mod_authz_host is so that host, IP, ENV, etc. can be used during authorization as well. This really wasn't as issue in 2.2 because the AND/OR/NOT logic didn't exist yet. Now that you can apply this type of logic to authorization, allowing host, IP, ENV, etc. to be part of that, make sense. If we moved mod_authz_host back to the 2.2 version, in the first place it would no longer be authz but just mod_access again and you wouldn't be able to include host, IP, ENV, etc. as part of an authorization rule. But I agree that mod_access_compat name no longer makes sense. Brad
Re: svn commit: r534533 - in /httpd/httpd/trunk: include/http_core.h modules/aaa/mod_access_compat.c modules/aaa/mod_auth.h modules/aaa/mod_authz_core.c modules/aaa/mod_authz_default.c server/core.c s
On 5/2/2007 at 1:47 PM, in message [EMAIL PROTECTED], Joshua Slive [EMAIL PROTECTED] wrote: On 5/2/07, Brad Nicholes [EMAIL PROTECTED] wrote: Yeah, that's where I mentioned that things might look a little confusing. There actually is a good reason to have both and yes some of the functionality can overlap. The reason for having mod_authz_host is so that host, IP, ENV, etc. can be used during authorization as well. This really wasn't as issue in 2.2 because the AND/OR/NOT logic didn't exist yet. Now that you can apply this type of logic to authorization, allowing host, IP, ENV, etc. to be part of that, make sense. If we moved mod_authz_host back to the 2.2 version, in the first place it would no longer be authz but just mod_access again and you wouldn't be able to include host, IP, ENV, etc. as part of an authorization rule. But I agree that mod_access_compat name no longer makes sense. What kinds of configurations are we actually talking about where Require ip could do things that Order/Allow/Satisfy could not? I guess you are talking about things like SatisfyOne SatisfyAll Require user john Require ip 192.0.0 /SatisfyAll SatisfyAll Require user bob Require ip 191.0.0 /SatisfyAll /SatisfyOne Is that kind of configuration really common enough to justify the added complexity of two different access-control systems? (It can be accomplished in current versions using some Alias/Location hacks or with mod_rewrite.) My opinion is that either we get rid of Require ip or we fix the hook ordering so that Order/Allow/Satisfy/etc can really be deprecated. Joshua. Correct, except I am thinking something more like: SatisfyOne SatisfyAll Require user john SatisfyOne Require ip 192.0.0 Require ip 137.65.0 Require host myhost.org /SatisfyOne /SatisfyAll SatisfyAll Require group admins SatisfyOne Require ip 10.10.0.0 Require ldap-attribute status=highest /SatisfyOne /SatisfyAll /SatisfyOne Which may be a bit more complicated to try to duplicate using other means. Besides, it seems to be a lot more straight forward to keep all of the authorization logic in one place rather than bits and pieces spread out in mod_rewrite rules or alias/location hacks. I'm all for figuring out a way to rework the hooks so that Order/Allow/Satisfy/etc. can really be deprecated. That is what my original intention was. However, after revisiting this issue, I'm not sure how to do it yet. Brad
Re: SatisfyOne
On 4/30/2007 at 10:13 AM, in message [EMAIL PROTECTED], Patrick Welche [EMAIL PROTECTED] wrote: On Fri, Apr 27, 2007 at 03:44:08PM -0600, Brad Nicholes wrote: On 4/27/2007 at 11:30 AM, in message [EMAIL PROTECTED], Patrick Welche [EMAIL PROTECTED] wrote: ... Using httpd trunk 529626, of Apr 19 2007, I tried a FAQ configuration with the new authentication framework: Directory /usr/local/share/httpd/htdocs/learn AuthType basic AuthName raven test AuthBasicProvider file AuthUserFile /usr/local/etc/pass.txt SatisfyOne Require host quartz.itdept.newn.cam.ac.uk Require ip 192.168.200.180 Require valid-user /SatisfyOne /Directory ... It's beginning to look like Order, Allow, Deny, Satisfy can't be deprecated after all. However I still think that there is a usefulness for the same type of authorization rules defined by require. Indeed, translating to the compat form: Directory /usr/local/share/httpd/htdocs/learn AuthType basic AuthName raven test AuthBasicProvider file AuthBasicAuthoritative Off AuthUserFile /usr/local/etc/httppwddb Order Deny,Allow Deny from All Allow from quartz.itdept.newn.cam.ac.uk 192.168.200.180 Require valid-user Satisfy Any /Directory behaves as expected. Cheers, Patrick I'm a little surprised to hear that. Are you sure that you cleared out your authenticated session cache before you tested the new configuration? As the code stands now, you would have had to go through the authentication hook which no matter what the access_control hook said, would have forced a prompt for a user name and password if it didn't already exist in the header. It's always good to hear that things are working correctly, but in this case I am a little surprised. Brad
Re: SatisfyOne
On 4/30/2007 at 9:54 AM, in message [EMAIL PROTECTED], Joshua Slive [EMAIL PROTECTED] wrote: On 4/27/07, Brad Nicholes [EMAIL PROTECTED] wrote: It's beginning to look like Order, Allow, Deny, Satisfy can't be deprecated after all. However I still think that there is a usefulness for the same type of authorization rules defined by require. I don't really understand why you say this. Isn't it just a question of defining the order of evaluation of SatisfyOne blocks? And the proper order seems quite straight-forward to me. Joshua. Well, the reason why is because of the order in which the hooks are called . We have three different hooks, access_checker, check_user_id and auth_checker. Basically, to give the hooks more understandable names, we have access_control, authentication and authorization. The directives that cause these hooks to be invoked are: Order, Allow from, Deny from- access_control hook AuthBasicProvider, AuthDigestProvider - Authentication hook Require - Authorization hook With the host based directives moving from Allow from [host|IP|ENV], Deny From [host|IP|ENV] to Require [host|IP|ENV], Reject [host|IP|ENV], the access control functionality moved from the access_control hook to the Authorization hook. This works great until you try to throw authentication into the mix. If your intention was to avoid a credentials challenge through access control, as soon as you include authentication, the check_user_id hook gets called and the first thing that happens is a check for the user name and password in the request header. If it isn't there, the challenge is sent back to the browser and the browser prompts for the user name and password. In this case there was no chance for Require [host|IP] to even have a crack at satisfying the request since the authorization hook was never called. When I implemented this I thought I had all of the bases covered but apparently not (which is why I would like to see us at least roll an alpha of 2.3 so this stuff would get some visibility). There seems to be cases where access control and authorization should be separate. So I am starting to see the need to retain Order, Allow, Deny, Satisfy so that in cases where access control needs to happen outside of authorization, it can. I don't really like having to retain those directives, because it makes access control and authorization a little more confusing. Better ideas? Brad
Re: SatisfyOne
On 4/27/2007 at 11:30 AM, in message [EMAIL PROTECTED], Patrick Welche [EMAIL PROTECTED] wrote: Basically, bug or configuration error? Using httpd trunk 529626, of Apr 19 2007, I tried a FAQ configuration with the new authentication framework: Directory /usr/local/share/httpd/htdocs/learn AuthType basic AuthName raven test AuthBasicProvider file AuthUserFile /usr/local/etc/pass.txt SatisfyOne Require host quartz.itdept.newn.cam.ac.uk Require ip 192.168.200.180 Require valid-user /SatisfyOne /Directory quartz% hostname quartz.itdept.newn.cam.ac.uk quartz% lynx http://test.itdept.newn.cam.ac.uk/learn Alert!: Access without authorization denied -- retrying Username for 'raven test' at server 'test.itdept.newn.cam.ac.uk': I expected not to be prompted to login by the above configuration. (also tried AuthBasicAuthoritative Off, and have read the fine manual..) Cheers, Patrick This is probably a bug. The problem is that as soon as you specify an Auth provider, the code is going to go through the check_user_id hook. The first thing that auth_basic will do in the hook is try to get the user and password. If it can't, it immediately returns HTTP_UNAUTHORIZED which causes the browser challenge. You can still use mod_access_compat and define access control rules which is probably what you really want rather than authorization rules, which is what you have defined here. However there is still a problem in ap_process_request_internal() in request.c. In the current code, there is no precedence defined between access control and authentication. All hooks will be called on all requests. We can either set the precedence at the time when the hooks are called (which will prevent some hooks from being called) or let the auth hooks themselves determine the precedence. It's beginning to look like Order, Allow, Deny, Satisfy can't be deprecated after all. However I still think that there is a usefulness for the same type of authorization rules defined by require. Brad
Re: mod_ftp, status and progress?
On 4/26/2007 at 4:16 PM, in message [EMAIL PROTECTED], Guenter Knauf [EMAIL PROTECTED] wrote: Hi, Wouldn't it be better to focus on 2.2.x and onwards? OK, there's a lot of people still running 1.3 and 2.0, but that doesn't mean that we have to make it run on all of them... I'm all for focusing on getting it usable for 2.2+, and if people it compile and runs fine with 2.2.x at least on Linux and Win32, so there's nothing to focus on. It does however not compile with 2.3.x trunk due to removal of ap_requires()... Guenter. Sounds like it need to be ported to use the new provider based authz. Brad
Re: bug with Apache 1.3 NetWare build system
On 4/19/2007 at 11:36 AM, in message [EMAIL PROTECTED], Guenter Knauf [EMAIL PROTECTED] wrote: Hi Brad, I've just found that we have same bug in the AP13 build system as what I fixed long time ago with the AP2x build system already; in each NWGNUmakefile.mak you can read: # # These flags will be added to the link.opt file # XLFLAGS += \ $(EOLIST) but in fact the XLFLAGS dont go into the link.opt file but instead into the link.def file. This does not work, and I'm unable to add additional libraries for linking the following patch fixes this: --- NWGNUtail.inc.origWed Jul 12 10:16:06 2006 +++ NWGNUtail.inc Thu Apr 19 19:25:24 2007 @@ -220,7 +220,7 @@ @echo -l $(REGEX)\$(OBJDIR) $@ @echo -l $(STDMOD)\$(OBJDIR) $@ @echo -l $(NWOS)\$(OBJDIR) $@ -#@echo -l $(METROWERKS)\Novell Support\Metrowerks Support\Libraries\Runtime $@ +#@echo -l $(METROWERKS)\Novell Support\Metrowerks Support\Libraries\Runtime $@ @echo -l $(NWSDKDIR)\imports $@ @echo -l $(LDAPSDK)\Netware\clib\imports $@ @echo -nodefaults $@ @@ -240,6 +240,9 @@ ifneq $(NLM_FLAGS) @echo -flags $(NLM_FLAGS) $@ endif +ifneq $(strip $(XLFLAGS)) + @echo $(strip $(XLFLAGS)) $@ +endif ifneq $(strip $(FILES_nlm_objs)) @echo $(foreach objfile,$(strip $(FILES_nlm_objs)),$(subst /,\,$(objfile))) $@ endif @@ -262,9 +265,6 @@ ifneq $(FILES_nlm_exports) @echo Export $(foreach export,$(subst $(SPACE),$(COMMA),$(strip $(FILES_nlm_exports))),$(subst /,\,$(export))) $(OBJDIR)\$(NLM_NAME)_link.def endif -ifneq $(strip $(XLFLAGS)) - @echo $(strip $(XLFLAGS)) $(OBJDIR)\$(NLM_NAME)_link.def -endif #ifndef XDCFOUND #@echo XDCData $(NWOS)\apache.xdc $(OBJDIR)\$(NLM_NAME)_link.def #endif can we get this into the Apache 1.3 source tree? thanks, Guenter. +1, go ahead and commit it. Brad
Re: [PATCH] add experimental modules makefiles for NetWare
On 3/9/2007 at 11:22 AM, in message [EMAIL PROTECTED], Guenter Knauf [EMAIL PROTECTED] wrote: Hi Brad, can you please commit the attached makefiles to the 'experimental' modules folder, and patch the existing NWGNUmakefile in order to pick up the new ones? Since its no code change probably also for the 2.2.x line? thanks, Guenter Already done in trunk. I still need to add them to 2.2 branch Brad
Re: util_ldap.c use of hardcoded sizelimit on ldap_search_ext_s causing error
Please submit a complete patch against trunk for the apr-util code that
includes the ZOS define. This should include the makefile magic that defines
APR_HAS_ZOS_LDAPSDK as well. Also include a patch for util_ldap.c that will
define APR_LDAP_SIZELIMIT if the version of apr-util does not include the
#define.
Brad
On Wed, Mar 7, 2007 at 8:36 AM, in message
[EMAIL PROTECTED], David Jones
[EMAIL PROTECTED] wrote:
Patch to commit if no further comments.
Note that it does not have the ZOS define yet, and does not synch apr- util
with httpd.
to avoid synch problems i could add to util_ldap:
#ifndef APR_LDAP_SIZELIMIT
#define APR_LDAP_SIZELIMIT - 1
#endif
Index: modules/ldap/util_ldap.c
==
=
--- modules/ldap/util_ldap.c(revision 510991)
+++ modules/ldap/util_ldap.c(working copy)
@@ - 52,9 +52,6 @@
#define LDAP_CA_TYPE_BASE64 2
#define LDAP_CA_TYPE_CERT7_DB 3
- #ifndef LDAP_NO_LIMIT
- #define LDAP_NO_LIMIT - 1
- #endif
module AP_MODULE_DECLARE_DATA ldap_module;
@@ - 660,7 +657,7 @@
/* search for reqdn */
if ((result = ldap_search_ext_s(ldc- ldap, (char *)reqdn,
LDAP_SCOPE_BASE,
(objectclass=*), NULL, 1,
- NULL, NULL, NULL, LDAP_NO_LIMIT,
res))
+NULL, NULL, NULL, APR_LDAP_SIZELIMIT,
res))
== LDAP_SERVER_DOWN)
{
ldc- reason = DN Comparison ldap_search_ext_s()
@@ - 938,7 +935,7 @@
if ((result = ldap_search_ext_s(ldc- ldap,
(char *)basedn, scope,
(char *)filter, attrs, 0,
- NULL, NULL, NULL, LDAP_NO_LIMIT,
res))
+NULL, NULL, NULL, APR_LDAP_SIZELIMIT,
res))
== LDAP_SERVER_DOWN)
{
ldc- reason = ldap_search_ext_s() for user failed with server
down;
@@ - 1178,7 +1175,7 @@
if ((result = ldap_search_ext_s(ldc- ldap,
(char *)basedn, scope,
(char *)filter, attrs, 0,
- NULL, NULL, NULL, LDAP_NO_LIMIT,
res))
+NULL, NULL, NULL, APR_LDAP_SIZELIMIT,
res))
== LDAP_SERVER_DOWN)
{
ldc- reason = ldap_search_ext_s() for user failed with server
down;
Index: apr- util/include/apr_ldap.h.in
===
--- apr- util/include/apr_ldap.h.in(revision 515593)
+++ apr- util/include/apr_ldap.h.in(working copy)
@@ - 93,6 +93,15 @@
#define LDAPS_PORT 636 /* ldaps:/// default LDAP over TLS port */
#endif
+/*
+ * For ldap function calls that input a size limit on the number of
returned entries.
+ * Some SDKs do not have the define for LDAP_DEFAULT_LIMIT (- 1) or
LDAP_NO_LIMIT (0)
+ */
+#ifdef LDAP_DEFAULT_LIMIT
+#define APR_LDAP_SIZELIMIT LDAP_DEFAULT_LIMIT
+#else
+#define APR_LDAP_SIZELIMIT - 1 /* equivalent to LDAP_DEFAULT_LIMIT */
+#endif
/* Note: Macros defining const casting has been removed in APR v1.0,
* pending real support for LDAP v2.0 toolkits.
On 3/2/07, Brad Nicholes [EMAIL PROTECTED] wrote:
Looks good, I think I like your first suggestion better, putting the
#ifdef in apr_ldap.h.in. This seems a little more straight forward rather
than hiding the value in configure.
Brad
On 3/1/2007 at 7:07 PM, in message
[EMAIL PROTECTED], David
Jones
[EMAIL PROTECTED] wrote:
How about:
changes to apr_ldap.h.in:
#define APR_HAS_ZOS_LDAPSDK @apu_has_ldap_zos@
#if APR_LDAP_HAS_ZOS_LDAPSDK
#define APR_LDAP_SIZELIMIT LDAP_NO_LIMIT
#else
#ifdef LDAP_DEFAULT_LIMIT
#define APR_LDAP_SIZELIMIT LDAP_DEFAULT_LIMIT
#else
#define APR_LDAP_SIZELIMIT - 1 /* equivalent to LDAP_DEFAULT_LIMIT */
#endif
#endif
This part of the util_ldap.c patch at the bottom could allow
util_ldap.c to
compile regardless of apr- util level, but would not typically commit it?
+#ifndef APR_LDAP_SIZELIMIT
+#define APR_LDAP_SIZELIMIT - 1
#endif
Or could add info to apu- conf.m4 for each SDK, eliminating the need for
the
ZOS specific #if (would just need #define APR_LDAP_SIZELIMIT
@apu_ldap_sizelimit)
(If get any input from other SDKs then could replace its - 1 with
LDAP_DEFAULT_LIMIT or LDAP_NO_LIMIT as i did for z/OS)
Index: apu- conf.m4
===
RCS file: /m0xa/cvs/phoenix/2.2.4/srclib/apr- util/build/apu- conf.m4,v
retrieving revision 1.2
diff - u - d - b - r1.2 apu- conf.m4
--- apu- conf.m4 12 Feb 2007 18:19:20 - 1.2
+++ apu- conf.m4 1 Mar 2007 20:07:26 -
@@ - 267,10 +273,13 @@
apu_has_ldap_sslinit=0
apu_has_ldapssl_install_routines=0
Re: util_ldap.c use of hardcoded sizelimit on ldap_search_ext_s causing error
Looks good, I think I like your first suggestion better, putting the #ifdef in apr_ldap.h.in. This seems a little more straight forward rather than hiding the value in configure. Brad On 3/1/2007 at 7:07 PM, in message [EMAIL PROTECTED], David Jones [EMAIL PROTECTED] wrote: How about: changes to apr_ldap.h.in: #define APR_HAS_ZOS_LDAPSDK @apu_has_ldap_zos@ #if APR_LDAP_HAS_ZOS_LDAPSDK #define APR_LDAP_SIZELIMIT LDAP_NO_LIMIT #else #ifdef LDAP_DEFAULT_LIMIT #define APR_LDAP_SIZELIMIT LDAP_DEFAULT_LIMIT #else #define APR_LDAP_SIZELIMIT -1 /* equivalent to LDAP_DEFAULT_LIMIT */ #endif #endif This part of the util_ldap.c patch at the bottom could allow util_ldap.c to compile regardless of apr-util level, but would not typically commit it? +#ifndef APR_LDAP_SIZELIMIT +#define APR_LDAP_SIZELIMIT -1 #endif Or could add info to apu-conf.m4 for each SDK, eliminating the need for the ZOS specific #if (would just need #define APR_LDAP_SIZELIMIT @apu_ldap_sizelimit) (If get any input from other SDKs then could replace its -1 with LDAP_DEFAULT_LIMIT or LDAP_NO_LIMIT as i did for z/OS) Index: apu-conf.m4 === RCS file: /m0xa/cvs/phoenix/2.2.4/srclib/apr-util/build/apu-conf.m4,v retrieving revision 1.2 diff -u -d -b -r1.2 apu-conf.m4 --- apu-conf.m4 12 Feb 2007 18:19:20 - 1.2 +++ apu-conf.m4 1 Mar 2007 20:07:26 - @@ -267,10 +273,13 @@ apu_has_ldap_sslinit=0 apu_has_ldapssl_install_routines=0 apu_has_ldap_openldap=0 +apu_has_ldap_sizelimit=0 @@ -354,42 +363,57 @@ AC_EGREP_CPP([OpenLDAP], [$lber_h $ldap_h LDAP_VENDOR_NAME], [apu_has_ldap_openldap=1 + apu_ldap_sizelimit=-1 apr_cv_ldap_toolkit=OpenLDAP]) fi if test x$apr_cv_ldap_toolkit = x; then AC_EGREP_CPP([Sun Microsystems Inc.], [$lber_h $ldap_h LDAP_VENDOR_NAME], [apu_has_ldap_solaris=1 + apu_ldap_sizelimit=-1 apr_cv_ldap_toolkit=Solaris]) fi if test x$apr_cv_ldap_toolkit = x; then AC_EGREP_CPP([Novell], [$lber_h $ldap_h LDAP_VENDOR_NAME], [apu_has_ldap_novell=1 + apu_ldap_sizelimit=-1 apr_cv_ldap_toolkit=Novell]) fi if test x$apr_cv_ldap_toolkit = x; then AC_EGREP_CPP([Microsoft Corporation.], [$lber_h $ldap_h LDAP_VENDOR_NAME], [apu_has_ldap_microsoft=1 + apu_ldap_sizelimit=-1 apr_cv_ldap_toolkit=Microsoft]) fi if test x$apr_cv_ldap_toolkit = x; then AC_EGREP_CPP([Netscape Communications Corp.], [$lber_h $ldap_h LDAP_VENDOR_NAME], [apu_has_ldap_netscape=1 + apu_ldap_sizelimit=-1 apr_cv_ldap_toolkit=Netscape]) fi if test x$apr_cv_ldap_toolkit = x; then AC_EGREP_CPP([mozilla.org], [$lber_h $ldap_h LDAP_VENDOR_NAME], [apu_has_ldap_mozilla=1 + apu_ldap_sizelimit=-1 apr_cv_ldap_toolkit=Mozilla]) fi if test x$apr_cv_ldap_toolkit = x; then + AC_EGREP_CPP([IBM], [$lber_h + $ldap_h + LDAP_VENDOR_NAME], [apu_has_ldap_zos=1 + apu_ldap_sizelimit=LDAP_NO_LIMIT + apr_cv_ldap_toolkit=ZOS]) +fi +if test x$apr_cv_ldap_toolkit = x; then apu_has_ldap_other=1 + apu_ldap_sizelimit=-1 apr_cv_ldap_toolkit=unknown fi + ]) fi @@ -398,15 +422,20 @@ LIBS=$save_libs ]) +AC_SUBST(apu_ldap_sizelimit) AC_SUBST(ldap_h) AC_SUBST(lber_h) AC_SUBST(ldap_ssl_h) @@ -415,6 +444,7 @@ AC_SUBST(apu_has_ldap_microsoft) AC_SUBST(apu_has_ldap_netscape) AC_SUBST(apu_has_ldap_mozilla) +AC_SUBST(apu_has_ldap_zos) AC_SUBST(apu_has_ldap_other) ]) And finally this same either way except for the question on #ifndef APR_LDAP_SIZELIMIT Index: util_ldap.c === RCS file: /m0xa/cvs/phoenix/2.2.4/modules/ldap/util_ldap.c,v retrieving revision 1.3 diff -u -d -b -r1.3 util_ldap.c --- util_ldap.c 15 Feb 2007 18:55:41 - 1.3 +++ util_ldap.c 1 Mar 2007 20:19:39 - @@ -45,15 +45,8 @@ #include unixd.h #endif -#ifndef
Re: util_ldap.c use of hardcoded sizelimit on ldap_search_ext_s causing error
LDAP SDK differences should really be pushed down into APR-Util. In fact your
option #1 would probably be the way to go as long as it was implemented in
apr_ldap.h.in and you implemented APR_HAS_ZOS_LDAPSDK that is determined during
configure time just like the other SDKs. The #define should also be prefixed
with APR_. Unfortunately this creates a version dependancy between HTTPD and
APR-Util. This is OK for trunk but a problem for 2.2. The release of APR-Util
and HTTPD would have to be coordinated. The fallback is to patch util_ldap.c
in some way that doesn't alter the way that the other platforms or SDKs are
currently working.
Brad
On 2/28/2007 at 8:26 AM, in message
[EMAIL PROTECTED], David Jones
[EMAIL PROTECTED] wrote:
Sorry for the delay.
We use our own z/OS specific SDK. There is also a Tivoli SDK , [see Eric
Covener's appends and
http://issues.apache.org/bugzilla/attachment.cgi?id=19394 waiting for
input], which shares some commonality with z/OS (Tivoli can accept the -1
without a problem, but it acts like 0).
Thoughts are:
1) LDAP_HAS_ZOS_LDAPSDK isn't an apache define yet. (The Tivoli append adds
a LDAP_HAS_TIVOLI_LDAPSDK to apu-conf.m4, and we would do similar). So if it
shouldn't be put in svn yet skip the top 3 lines and what we're left with
isn't much different than the original hardcoded -1, but at least it puts
some doc in the code about whats going on.
#ifdef LDAP_HAS_ZOS_LDAPSDK
#define LDAP_LIMIT_VALUE LDAP_NO_LIMIT
#else
#ifdef LDAP_DEFAULT_LIMIT
#define LDAP_LIMIT_VALUE LDAP_DEFAULT_LIMIT
#else
#define LDAP_LIMIT_VALUE -1 /* equivalent to LDAP_DEFAULT_LIMIT */
#endif
#endif
2)Or the flipside, assuming everyone else who defines 0 and not -1 wants to
use 0:
#ifdef LDAP_HAS_NOVELL_LDAPSDK
#define LDAP_LIMIT_VALUE -1
#else
#ifdef LDAP_DEFAULT_LIMIT
#define LDAP_LIMIT_VALUE LDAP_DEFAULT_TIME
#else
#ifdef LDAP_NO_LIMIT
#define LDAP_LIMIT_VALUE LDAP_NO_LIMIT
#else
#define LDAP_LIMIT_VALUE -1
#endif
#endif
#endif
3) Or maybe moving it and define a APR_LDAP_DEFAULT_SIZELIMIT instead of
keeping it in util_ldap.c
4) Or some complicated(?) conf magic that would involve getting a handle and
then calling ldap_set_option(ldap, LDAP_OPT_SIZELIMIT, -1); and setting
APR_LDAP_DEFAULT_SIZELIMIT to -1 or 0 accordingly.
On 2/23/07, Brad Nicholes [EMAIL PROTECTED] wrote:
What LDAP client SDK does z/OS use? (Novell, OpenLDAP, Netscape, Other???)
Brad
On 2/22/2007 at 12:52 PM, in message
[EMAIL PROTECTED], David
Jones
[EMAIL PROTECTED] wrote:
Its the z/OS, has LDAP_NO_SIZELIMIT defined. Does not have nor support
LDAP_DEFAULT_SIZELIMIT
On 2/22/07, Brad Nicholes [EMAIL PROTECTED] wrote:
On 2/22/2007 at 7:12 AM, in message
[EMAIL PROTECTED], David
Jones
[EMAIL PROTECTED] wrote:
How about something alone these lines? It assumes there is nobody
with
LDAP_DEFAULT_LIMIT undefined AND LDAP_NO_LIMIT defined, but still
supports
and wishes to use the -1 value.
--- util_ldap.c.defaultlimitWed Feb 21 16:08:51 2007
+++ util_ldap.c.nolimit Thu Feb 15 12:50:09 2007
@@ -52,15 +52,9 @@
#define LDAP_CA_TYPE_BASE64 2
#define LDAP_CA_TYPE_CERT7_DB 3
-#ifdef LDAP_DEFAULT_LIMIT
-#define LDAP_LIMIT_VALUE LDAP_DEFAULT_LIMIT
-#else
-#ifndef LDAP_NO_LIMIT /* Have neither LDAP_DEFAULT_LIMIT or
LDAP_NO_LIMIT
*/
-#define LDAP_LIMIT_VALUE -1
-#else /* Have LDAP_NO_LIMIT, but not
LDAP_DEFAULT_LIMIT */
-#define LDAP_LIMIT_VALUE LDAP_NO_LIMIT
-#endif /* !LDAP_NO_LIMIT */
-#endif /* LDAP_DEFAULT_LIMIT */
+#ifndef LDAP_NO_LIMIT
+#define LDAP_NO_LIMIT -1
+#endif
module AP_MODULE_DECLARE_DATA ldap_module;
@@ -680,7 +674,7 @@
/* search for reqdn */
if ((result = ldap_search_ext_s(ldc-ldap, (char *)reqdn,
LDAP_SCOPE_BASE,
(objectclass=*), NULL, 1,
-NULL, NULL, NULL,
LDAP_LIMIT_VALUE,
res))
+NULL, NULL, NULL, LDAP_NO_LIMIT,
res))
== LDAP_SERVER_DOWN)
{
ldc-reason = DN Comparison ldap_search_ext_s()
@@ -958,7 +952,7 @@
if ((result = ldap_search_ext_s(ldc-ldap,
(char *)basedn, scope,
(char *)filter, attrs, 0,
-NULL, NULL, NULL,
LDAP_LIMIT_VALUE,
res))
+NULL, NULL, NULL, LDAP_NO_LIMIT,
res))
== LDAP_SERVER_DOWN)
{
ldc-reason = ldap_search_ext_s() for user failed with
server
down;
@@ -1198,7 +1192,7 @@
if ((result = ldap_search_ext_s(ldc-ldap,
(char *)basedn, scope,
(char *)filter, attrs, 0
Re: util_ldap.c use of hardcoded sizelimit on ldap_search_ext_s causing error
What LDAP client SDK does z/OS use? (Novell, OpenLDAP, Netscape, Other???)
Brad
On 2/22/2007 at 12:52 PM, in message
[EMAIL PROTECTED], David Jones
[EMAIL PROTECTED] wrote:
Its the z/OS, has LDAP_NO_SIZELIMIT defined. Does not have nor support
LDAP_DEFAULT_SIZELIMIT
On 2/22/07, Brad Nicholes [EMAIL PROTECTED] wrote:
On 2/22/2007 at 7:12 AM, in message
[EMAIL PROTECTED], David
Jones
[EMAIL PROTECTED] wrote:
How about something alone these lines? It assumes there is nobody with
LDAP_DEFAULT_LIMIT undefined AND LDAP_NO_LIMIT defined, but still
supports
and wishes to use the -1 value.
--- util_ldap.c.defaultlimitWed Feb 21 16:08:51 2007
+++ util_ldap.c.nolimit Thu Feb 15 12:50:09 2007
@@ -52,15 +52,9 @@
#define LDAP_CA_TYPE_BASE64 2
#define LDAP_CA_TYPE_CERT7_DB 3
-#ifdef LDAP_DEFAULT_LIMIT
-#define LDAP_LIMIT_VALUE LDAP_DEFAULT_LIMIT
-#else
-#ifndef LDAP_NO_LIMIT /* Have neither LDAP_DEFAULT_LIMIT or
LDAP_NO_LIMIT
*/
-#define LDAP_LIMIT_VALUE -1
-#else /* Have LDAP_NO_LIMIT, but not
LDAP_DEFAULT_LIMIT */
-#define LDAP_LIMIT_VALUE LDAP_NO_LIMIT
-#endif /* !LDAP_NO_LIMIT */
-#endif /* LDAP_DEFAULT_LIMIT */
+#ifndef LDAP_NO_LIMIT
+#define LDAP_NO_LIMIT -1
+#endif
module AP_MODULE_DECLARE_DATA ldap_module;
@@ -680,7 +674,7 @@
/* search for reqdn */
if ((result = ldap_search_ext_s(ldc-ldap, (char *)reqdn,
LDAP_SCOPE_BASE,
(objectclass=*), NULL, 1,
-NULL, NULL, NULL, LDAP_LIMIT_VALUE,
res))
+NULL, NULL, NULL, LDAP_NO_LIMIT,
res))
== LDAP_SERVER_DOWN)
{
ldc-reason = DN Comparison ldap_search_ext_s()
@@ -958,7 +952,7 @@
if ((result = ldap_search_ext_s(ldc-ldap,
(char *)basedn, scope,
(char *)filter, attrs, 0,
-NULL, NULL, NULL, LDAP_LIMIT_VALUE,
res))
+NULL, NULL, NULL, LDAP_NO_LIMIT,
res))
== LDAP_SERVER_DOWN)
{
ldc-reason = ldap_search_ext_s() for user failed with server
down;
@@ -1198,7 +1192,7 @@
if ((result = ldap_search_ext_s(ldc-ldap,
(char *)basedn, scope,
(char *)filter, attrs, 0,
-NULL, NULL, NULL, LDAP_LIMIT_VALUE,
res))
+NULL, NULL, NULL, LDAP_NO_LIMIT,
res))
== LDAP_SERVER_DOWN)
{
ldc-reason = ldap_search_ext_s() for user failed with server
down;
Maybe I missed this before, but what platform or LDAP SDK does this fail
on? The Novell LDAP SDK obviously supports LDAP_DEFAULT_SIZELIMIT (-1) and
according to the OpenLDAP source code, it also supports the same
functionality if the value of sizelimit is -1 even though it does not
specifically define LDAP_DEFAULT_SIZELIMIT. I don't know what the Netscape
or Microsoft SDKs support other than the fact that we have been passing
those SDKs the same -1 value without a problem. I believe that the only
reason why we see the hardcoded -1 rather than a #define is simply because
not all of the SDKs provide a #define yet they all seems to support the
functionality. We just need to validate that theory.
Brad
Re: util_ldap.c use of hardcoded sizelimit on ldap_search_ext_s causing error
On 2/22/2007 at 7:12 AM, in message
[EMAIL PROTECTED], David Jones
[EMAIL PROTECTED] wrote:
How about something alone these lines? It assumes there is nobody with
LDAP_DEFAULT_LIMIT undefined AND LDAP_NO_LIMIT defined, but still supports
and wishes to use the -1 value.
--- util_ldap.c.defaultlimitWed Feb 21 16:08:51 2007
+++ util_ldap.c.nolimit Thu Feb 15 12:50:09 2007
@@ -52,15 +52,9 @@
#define LDAP_CA_TYPE_BASE64 2
#define LDAP_CA_TYPE_CERT7_DB 3
-#ifdef LDAP_DEFAULT_LIMIT
-#define LDAP_LIMIT_VALUE LDAP_DEFAULT_LIMIT
-#else
-#ifndef LDAP_NO_LIMIT /* Have neither LDAP_DEFAULT_LIMIT or LDAP_NO_LIMIT
*/
-#define LDAP_LIMIT_VALUE -1
-#else /* Have LDAP_NO_LIMIT, but not LDAP_DEFAULT_LIMIT */
-#define LDAP_LIMIT_VALUE LDAP_NO_LIMIT
-#endif /* !LDAP_NO_LIMIT */
-#endif /* LDAP_DEFAULT_LIMIT */
+#ifndef LDAP_NO_LIMIT
+#define LDAP_NO_LIMIT -1
+#endif
module AP_MODULE_DECLARE_DATA ldap_module;
@@ -680,7 +674,7 @@
/* search for reqdn */
if ((result = ldap_search_ext_s(ldc-ldap, (char *)reqdn,
LDAP_SCOPE_BASE,
(objectclass=*), NULL, 1,
-NULL, NULL, NULL, LDAP_LIMIT_VALUE,
res))
+NULL, NULL, NULL, LDAP_NO_LIMIT, res))
== LDAP_SERVER_DOWN)
{
ldc-reason = DN Comparison ldap_search_ext_s()
@@ -958,7 +952,7 @@
if ((result = ldap_search_ext_s(ldc-ldap,
(char *)basedn, scope,
(char *)filter, attrs, 0,
-NULL, NULL, NULL, LDAP_LIMIT_VALUE,
res))
+NULL, NULL, NULL, LDAP_NO_LIMIT, res))
== LDAP_SERVER_DOWN)
{
ldc-reason = ldap_search_ext_s() for user failed with server
down;
@@ -1198,7 +1192,7 @@
if ((result = ldap_search_ext_s(ldc-ldap,
(char *)basedn, scope,
(char *)filter, attrs, 0,
-NULL, NULL, NULL, LDAP_LIMIT_VALUE,
res))
+NULL, NULL, NULL, LDAP_NO_LIMIT, res))
== LDAP_SERVER_DOWN)
{
ldc-reason = ldap_search_ext_s() for user failed with server
down;
Maybe I missed this before, but what platform or LDAP SDK does this fail on?
The Novell LDAP SDK obviously supports LDAP_DEFAULT_SIZELIMIT (-1) and
according to the OpenLDAP source code, it also supports the same functionality
if the value of sizelimit is -1 even though it does not specifically define
LDAP_DEFAULT_SIZELIMIT. I don't know what the Netscape or Microsoft SDKs
support other than the fact that we have been passing those SDKs the same -1
value without a problem. I believe that the only reason why we see the
hardcoded -1 rather than a #define is simply because not all of the SDKs
provide a #define yet they all seems to support the functionality. We just
need to validate that theory.
Brad
Re: util_ldap.c use of hardcoded sizelimit on ldap_search_ext_s causing error
On 2/19/2007 at 9:29 AM, in message [EMAIL PROTECTED], Jeff Trawick [EMAIL PROTECTED] wrote: On 2/15/07, David Jones [EMAIL PROTECTED] wrote: Currently util_ldap.c has a hard coded -1 as the search limit value (meaning infinite/no limit) on ldap_search_ext_s() calls. Some platforms cannot handle the -1, but need a 0. Linux, zoS (and others) have a LDAP_NO_LIMIT value in ldap.h. Below is a patch, allows those who have LDAP_NO_LIMIT value to take advantage of it, and others to continue using a -1 value. patch committed to trunk and proposed for backport 2.2.x my guess is that -1 is rarely/never the proper value, but that isn't so easy to confirm; hopefully the symbol is always available in modern SDK level The values of 0 and -1 have a different meaning at least in the Novell LDAP SDK. A value of 0 or LDAP_NO_LIMIT specifies that the search truely has no limit to the number of entries that will be returned. A value of -1 or LDAP_DEFAULT_SIZELIMIT specifies that the search should default to the session value or the value that was set in the session by LDAP_OPT_SIZELIMIT. Changing the sizelimit parameter from -1 to LDAP_NO_LIMIT in the calls to ldap_search_ext_s() removes the ability to control the size limit through the session options. In fact the patch that was submitted will cause the ldap_search_ext_s() function to act differently depending on whether the LDAP SDK has defined LDAP_NO_LIMIT or not. I can't confirm this because I haven't been able to find it documented for all SDKs but I would assume that the initial reason for specifying -1 rather than LDAP_NO_LIMIT or LDAP_DEFAULT_SIZELIMIT is because the intention was to make the call to ldap_search_ext_s() defer to the size limit specified in the session. But not all SDKs define LDAP_DEFAULT_SIZELIMIT, therefore -1 was hardcoded. Can those that know the OpenLDAP or Microsoft LDAP SDKs confirm that those SDKs support a -1 or LDAP_DEFAULT_SIZELIMIT? In the meantime, the patch should probably be revised to make sure that all platforms work the same rather than some supporting LDAP_NO_LIMIT and other supporting LDAP_DEFAULT_SIZELIMIT. The preference should be LDAP_DEFAULT_SIZELIMIT (-1). Brad
Re: svn commit: r509629 - /httpd/httpd/branches/2.2.x/STATUS
On 2/20/2007 at 11:32 AM, in message [EMAIL PROTECTED], Jeff Trawick [EMAIL PROTECTED] wrote: On 2/20/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: bnicholes Date: Tue Feb 20 08:23:19 2007 New Revision: 509629 URL: http://svn.apache.org/viewvc?view=revrev=509629 Log: vote Modified: httpd/httpd/branches/2.2.x/STATUS Modified: httpd/httpd/branches/2.2.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?view=diffrev=5 09629r1=509628r2=509629 = = --- httpd/httpd/branches/2.2.x/STATUS (original) +++ httpd/httpd/branches/2.2.x/STATUS Tue Feb 20 08:23:19 2007 @@ -180,3 +180,9 @@ * mod_ldap: Fix the search limit parameter to ldap_search_ext_s() http://svn.apache.org/viewvc?view=revrev=509237 +1: trawick + -0: bnicholes - The patch as it stands, could cause unpredictible + behavior across SDKs depending on whether or not the SDK + has defined LDAP_NO_LIMIT. The behavior of the ldap_search_ext_s() + call can be different if the sizelimit parameter is 0 vs -1. + At the very least, the patch needs to be revised so that the + behavior is common across all SDKs. Is this correct as far as you know? . 0 always means no client API limit . LDAP_NO_LIMIT, when defined, means no client API limit . when accepted as a parameter, -1 sometimes means some default (client API default?) and sometimes means unlimited (VERY UNCLEAR TO ME) . the search is always limited by the server limit, no matter what is specified in the clien Yes, the point of using LDAP_NO_LIMIT in the ldap_search_ext_s() call is to override the limit that was set in the session using LDAP_OPT_LIMITSIZE. AFAIK, a -1 will defer to the session setting where a 0 will specify unlimited no matter what (of course as you mentioned the search will always be limited by the server limit). According to the documentation, this is how the Novell SDK works. I would assume that since we have been passing a -1 into OpenLDAP without complaint, it is also working this way even through there isn't #define for LDAP_DEFAULT_SIZELIMIT -1. The point being that the patch assumes that 0 and -1 are equivalent, but they aren't. Brad
Re: [PATCH] enable another basedir during 'make install' for NetWare
On 1/20/2007 at 8:05 AM, in message [EMAIL PROTECTED], Guenter Knauf [EMAIL PROTECTED] wrote: Hi Brad, I have just created a patch which changes a couple of NWGNU* files in order to make it possible to specify another basedir during a 'make install' than using the hardcoded 'Apache2'. Since the conf files need also then changed I've also attached a second patch against mkconfNW.awk which takes care of this. I have created and tested these patches with httpd-2.2.4 sources, and with my tests it seems to work as expected - you can test the new feature with f.e.: make -f NWGNUmakefile install BASEDIR=apache22 would be great if you could commit this soon so that the next release includes it... In case the patches get modified through the list here you can download them: http://www.gknw.net/test/httpd_patches/ thanks, Guenter Guenter, Can you split this patch up into httpd, apr and apr-util and also create the diff file against trunk rather than 2.4? Since this patch spans all three projects, we are probably going to have a problem coordinating releases. So at the very least, can you make sure that each project builds properly without the BASEDIR env variable so that it doesn't break the current build process for NetWare? Brad
Re: Bug [and proposed patch] for mod_ldap
On 1/22/2007 at 11:45 AM, in message
[EMAIL PROTECTED], Fenlason,
Josh [EMAIL PROTECTED] wrote:
I'm running into a problem with mod_ldap on Windows. When I try to
authenticate without passing in a username, I get a 500 server error.
Since the browser doesn't get back a 401, it caches the user's
credentials and I have to restart the browser session in order to
attempt to login again.
This is only happening on Windows, so I'm sure it's a difference (bug?)
in the Microsoft LDAP SDK. Below is a proposed fix on top of Apache
2.2.4. I added the #if APR_HAS_MICROSOFT_LDAPSDK block.
modules/ldap/util_ldap.c (line 933):
/* try do the search */
if ((result = ldap_search_ext_s(ldc-ldap,
(char *)basedn, scope,
(char *)filter, attrs, 0,
NULL, NULL, NULL, -1, res))
== LDAP_SERVER_DOWN)
{
ldc-reason = ldap_search_ext_s() for user failed with server
down;
uldap_connection_unbind(ldc);
goto start_over;
}
#if APR_HAS_MICROSOFT_LDAPSDK
if ( result == LDAP_FILTER_ERROR )
{ // no username was supplied, so fail with invalid credentials
/* failure? if so - return */
ldc-reason = ldap_search_ext_s() to search for user failed;
ldap_msgfree(res);
uldap_connection_unbind(ldc);
return LDAP_INVALID_CREDENTIALS;
}
#endif
/* if there is an error (including LDAP_NO_SUCH_OBJECT) return now
*/
if (result != LDAP_SUCCESS) {
ldc-reason = ldap_search_ext_s() for user failed;
return result;
}
It would be great if this patch or something with similar affect could
be included in the next Apache 2.2 release. Thanks.
,
Josh.
P.S. I opened bug 41435 for this issue
Unfortunately a platform specific #ifdef in util_ldap.c wouldn't be
appropriate. The easiest fix would be to add another result check at the end
of authn_ldap_check_password() in mod_authnz_ldap.c. However, the purpose of
the #ifdef's there was to handle the fact that not all platforms supported the
macro LDAP_SECURITY_ERROR() that checked a specific set of security related
result codes. Adding a check for LDAP_FILTER_ERROR doesn't seem quite right
since that result code isn't really a security code even though it would solve
the problem for Win32. The other solution would be to abstract all of the LDAP
result codes into a set of APR_LDAP_xxx codes which is probably too big of a
changed for 2.2.x.
Other thoughts?
Brad
Re: [VOTE] httpd-2.2.4 release candidate for review
On 1/6/2007 at 12:41 AM, in message [EMAIL PROTECTED], William A. Rowe, Jr. [EMAIL PROTECTED] wrote: http://httpd.apache.org/dev/dist/ will soon (within the hour, upon resync) contain the following tarballs for approval httpd-2.2.4.tar.bz2 [.asc|.md5] httpd-2.2.4.tar.gz [.asc|.md5] httpd-2.2.4-win32-src.zip [.asc|.md5] +/-1 [ ] Release httpd 2.2.4 Let the voting begin, and kick off 2.2.5 efforts. I understand Jim is still interested in RM'ing 2.2.5 later this month. Bil +1 NetWare Brad
Re: PATCH #40075 - using ldap groups that contain DNs and usernames for AuthZ
On Mon, Dec 4, 2006 at 1:00 PM, in message
[EMAIL PROTECTED], Johanna Bromberg Craig
[EMAIL PROTECTED] wrote:
Hi,
I've addressed the feedback I received on my patch from Brad Nicholes
as follows:
I've reviewed all instances of util_ldap_compare() and
util_ldap_cache_comparedn() to confirm that each is protected from
cases where req- dn might be NULL or '\0'.
I've addressed the differences between AuthLDAPGroupAttributeDN,
AuthLDAPGroupAttribute, and AuthzLDAPRequireDN.
Thanks,
Johanna
I finally got some time to take a closer look at the patch. Although I like
the concept, I am still uncomfortable with the implementation from a
configuration point of view. I have attached a patch which is actually closer
to your first patch except it maintains the original functionality while
enhancing the AuthLDAPGroupAttribute directive to support attributes that may
contain a full DN. Actually, I think that was the original intent of
AuthLDAPGroupAttributeIsDN but it appears to have been broken along the way.
Anyway the proposed new syntax for AuthLDAPGroupAttribute is:
AuthLDAPGroupAttribute attribute [DN | UN] ...
where the keywords DN (Distinguished Name) and UN (User Name) can
optionally follow each attribute in the list. If neither of the keywords are
specified, then the attribute type follows the AuthLDAPGroupAttributeIsDN
setting. The AuthLDAPGroupAttributeIsDN setting determines if a DN is required
in the group comparison or not. If the AuthLDAPGroupAttribute list contains
any UN's, then AuthLDAPGroupAttributeIsDN must be set to OFF otherwise the
authorization will fail since it would be expecting to be able to resolve the
user object to a DN within the LDAP directory.
Let me know if this works for you,
BTW, this patch is against trunk rather than the 2.2.x branch.
Brad
Index: mod_authnz_ldap.c
===
--- mod_authnz_ldap.c (revision 489925)
+++ mod_authnz_ldap.c (working copy)
@@ -84,6 +84,7 @@
struct mod_auth_ldap_groupattr_entry_t {
char *name;
+char *type;
};
module AP_MODULE_DECLARE_DATA authnz_ldap_module;
@@ -647,8 +648,10 @@
#endif
grp = apr_array_push(sec-groupattr);
grp-name = member;
+grp-type = NULL;
grp = apr_array_push(sec-groupattr);
grp-name = uniquemember;
+grp-type = NULL;
#if APR_HAS_THREADS
apr_thread_mutex_unlock(sec-lock);
#endif
@@ -682,7 +685,6 @@
if(result != LDAP_SUCCESS) {
ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
auth_ldap authorise: User DN not found, %s, ldc-reason);
-return AUTHZ_DENIED;
}
req = (authn_ldap_request_t *)apr_pcalloc(r-pool,
@@ -719,13 +721,30 @@
getpid(), t);
for (i = 0; i sec-groupattr-nelts; i++) {
-ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
- [% APR_PID_T_FMT ] auth_ldap authorize: require
group:
- testing for %s: %s (%s), getpid(),
- ent[i].name, sec-group_attrib_is_dn ? req-dn :
req-user, t);
+result = 0;
-result = util_ldap_cache_compare(r, ldc, sec-url, t, ent[i].name,
- sec-group_attrib_is_dn ? req-dn : req-user);
+if (ent[i].type == NULL) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
+ [% APR_PID_T_FMT ] auth_ldap authorize: require
group:
+ testing for %s: %s (%s), getpid(),
+ ent[i].name, sec-group_attrib_is_dn ? req-dn :
req-user, t);
+
+result = util_ldap_cache_compare(r, ldc, sec-url, t, ent[i].name,
+ sec-group_attrib_is_dn ? req-dn
: req-user);
+} else if (req-dn != NULL strlen(req-dn) != 0
strcasecmp(ent[i].type, dn) == 0) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
+ [% APR_PID_T_FMT ] auth_ldap authorise: require
group:
+ testing for %s: %s (%s), getpid(),
+ ent[i].name, req-dn, t);
+result = util_ldap_cache_compare(r, ldc, sec-url, t, ent[i].name,
req-dn);
+} else if (req-user != NULL strlen(req-user) != 0
strcasecmp(ent[i].type, un) == 0) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
+ [% APR_PID_T_FMT ] auth_ldap authorise: require
group:
+ testing for %s: %s (%s), getpid(),
+ ent[i].name, req-user, t);
+result = util_ldap_cache_compare(r, ldc, sec-url, t, ent[i].name,
req-user);
+}
+
switch(result) {
case LDAP_COMPARE_TRUE: {
ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
@@ -1252,15 +1271,29 @@
static const char *mod_auth_ldap_add_group_attribute(cmd_parms *cmd, void
*config, const char *arg
Re: PATCH #40075 - using ldap groups that contain DNs and usernames for AuthZ
On 12/11/2006 at 12:36 PM, in message [EMAIL PROTECTED], Johanna Bromberg Craig [EMAIL PROTECTED] wrote: Hey, I've addressed the last rounds of comments to my patch to mod_authnz_ldap. I haven't heard anything for a week, so I'm wondering, can someone please review these changes? Thanks, Johann Johanna, Sorry I haven't been able to get back to this quickly. I have been swamped with my day job lately. I will try to find some time to review the patch and hopefully have something to commit soon. Brad
Re: how mod_authnz_ldap ldap provider is supposed to work as basic auth provider?
On 11/25/2006 at 4:37 PM, in message
[EMAIL PROTECTED], Piotr Wadas
[EMAIL PROTECTED] wrote:
Cite from
http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html
The authn_ldap authentication provider can be enabled through the
AuthBasicProvider directive using the ldap value.
This seems clear.
Now, I looked into apache 2.2.3 source (apt-get source
apache2-mpm-prefork), into mod_auth_basic.c, lines 75-80,
and see what I get:
if (!newp-provider-check_password) {
/* if it doesn't provide the appropriate function, reject it */
return apr_psprintf(cmd-pool,
The '%s' Authn provider doesn't support
Basic Authentication, newp-provider_name);
}
As far as I can see, mod_authnz_ldap does not provide a check_password
routine - but it does (1167-1170)
static const authn_provider authn_ldap_provider =
{
authn_ldap_check_password,
};
so, the question is, how using authn_ldap_provider is suppose to work
as basic_auth provider, if it really does work for now? On the other
hand, if I look into mod_authn_file.c, I can find (lines 158-162)
static const authn_provider authn_file_provider =
{
check_password,
[..]
So, it seems that there's really a need for a method named
check_password. Can anyone explain this to me? :)
Regards,
Piot
The actual name of the check_password function doesn't matter. All that
matters is that a check_password provider function as been implemented and
referenced through the authn_provider structure. As you noted in your message,
both authn_file and authn_ldap take care of this through the
authn_file_provider and authn_ldap_provider structures respectively.
Brad
Re: PATCH #40075 - using ldap groups that contain DNs and usernames for AuthZ
On 11/7/2006 at 1:07 PM, in message [EMAIL PROTECTED], Johanna Bromberg Craig [EMAIL PROTECTED] wrote: Hi, I've addressed the feedback I received on my patch from Brad Nicholes as follows: I've restored AuthLDAPGroupAttribute to its former syntax and added a new directive, AuthLDAPGroupAttributeDN, whose attribute type is taken to be dn regardless of the value of AuthLDAPGroupAttributeIsDN. AuthLDAPGroupAttributeDN uses the same syntax as AuthLDAPGroupAttribute for the sake of clarity. Thanks, Johann Hopefully I can get some time here soon to take a closer look at it. Brad
Re: Clarification on how check_user_id hook works
On 10/10/2006 at 8:58 AM, in message [EMAIL PROTECTED], Eric Covener [EMAIL PROTECTED] wrote: On 10/10/06, Javier Sagrera [EMAIL PROTECTED] wrote: So, i can write my modules, based on modules that i know will have a conflict with mine using the if ... but that is a little limited, i just find strange that you dont have control of the order in which the functions are call, Your example is a little contrived because an auth module already checked and accepted the userid. And even more strange, that the inclusion of a function registered with FIRST, will change the order too. You're sorting a list and have specified that you don't care about the position of two things relative to eachother. Seems reasonable that their position would change as the overall contents of the list changes based on implementation of the sort. Don't get me wrong, being able to influence the hook ordering with configuration directives sounds cool (e.g. DirectiveXYZ hook_name mod_homegrown.c after mod_thirdparty.c) but it doesn't look like there's a practical problem. The order in which the check_user_id hooks are called, isn't as big of an issue as you might think. In most cases, even if another module is called before yours, the first thing that it will do is check to make sure that it is configured for that Directory or Location and DECLINE to handle the request if not. Keep in mind that this is an Apache 2.0 and before issue. Apache 2.2 has solved this problem with providers. Using the AuthBasicProvider or AuthdigestProvider directives, you can specify which authentication providers will be called for a specific directory or location and in what order. Apache 2.3 goes even further to allow the same type of thing for authorization. Brad
Re: AuthProviderAlias and mod_authn_file
So it sounds like there are two questions being asked. First, what non-ldap usages are there for authnAlias and second why doesn't the configuration below work? I'll answer the second question first. Given the configuration block below, I don't know why it doesn't work. I just retested the same configuration and everything worked as expected. The only issue that I see is setting 'AuthBasicAuthoritative off'. Since there doesn't appear to be any other authentication type specified (ie. digest), this directive should either be set to 'on' or removed and left as default (which is also 'on'). The error message that is showing up in the error_log is a result of the default authn handler being hit as a last resort with no auth type set as default. BTW, given the configuration below, I was also unable to duplicate the error message even with AuthBasicAuthoritative set to 'on' which implies that there is probably some other auth configuration somewhere that is conflicting. To answer the first question, the non-ldap example given here is a perfectly valid use of authnAlias. Basically authnAlias can be used to create extended providers that use the same base provider but with different parameters. Another possible example would be authnDBD: AuthnProviderAlias dbd dbd1 AuthDBDUserPWQuery select password from authn where username = %s /AuthnProviderAlias AuthnProviderAlias dbd dbd2 AuthDBDUserPWQuery select password from authn where Aliasusername = %s /AuthnProviderAlias Of course you could craft a better SQL statement that would handle both situations at the same time, but you get the point. AuthAlias just appears to be more useful with LDAP because configuring authnzldap authentication usually requires more than a single directive that defines authentication criteria (ie. ldap server, bind user and password). Brad On 9/5/2006 at 6:54 AM, in message [EMAIL PROTECTED], Rich Bowen [EMAIL PROTECTED] wrote: This went first to users@, but it appears that the auth-fu isn't strong there right now. ;-) I was hoping that someone (Brad?) might be able to assist me with this. I was trying to come up with a non-LDAP example for the documentation, since this seems a really useful feature that should be accessible to folks that don't use LDAP. But so far no joy. Begin forwarded message: From: Rich Bowen [EMAIL PROTECTED] Date: September 4, 2006 16:34:45 EDT To: users@httpd.apache.org Subject: [EMAIL PROTECTED] AuthProviderAlias and mod_authn_file Reply-To: users@httpd.apache.org I'm trying to come up with a working example of using AuthProviderAlias with something other than LDAP. I'm sure I'm overlooking something simple, but I can't get it working, and could use some advice. Here's what I've got: AuthnProviderAlias file file1 AuthUserFile /tmp/auth1 /AuthnProviderAlias AuthnProviderAlias file file2 AuthUserFile /tmp/auth2 /AuthnProviderAlias Directory /usr/local/apache/vhosts/drbacchus/x AuthType Basic AuthName 'wooga' AuthBasicAuthoritative off AuthBasicProvider file1 file2 Require valid-user /Directory On trying to authenticate, I get the following in the error log: access to /x failed, reason: require directives present and no Authoritative handler. Any advice would be greatly appreciated. With any luck, I'll figure it out as soon as I press send ... -- They went to sea in a sieve, they did In a sieve they went to se
Re: [Vote] create [EMAIL PROTECTED]
On 9/1/2006 at 1:25 PM, in message [EMAIL PROTECTED], William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Project Committee Members... Adopt [EMAIL PROTECTED], +1
Re: configuration directives redux
On 8/3/2006 at 4:50 PM, in message [EMAIL PROTECTED], Chris Darroch [EMAIL PROTECTED] wrote: Hi -- Some time ago, I proposed this large patchset (better described, I think, by the message referenced by the second link below): http://marc.theaimsgroup.com/?l=apache-httpd-devm=114729206702495w=2 http://marc.theaimsgroup.com/?l=apache-httpd-devm=114788040600327w=2 The patches for the other four platforms (winnt, netware, beos, and mpmt_os2) I have no way of testing. If anyone with access to one or more of those platforms could test and review, that would be greatly appreciated! Appears to build and run on NetWare. Brad
Re: svn commit: r427780 - in /httpd/httpd/trunk: docs/manual/mod/mod_authz_core.xml modules/aaa/mod_
On 8/1/2006 at 5:34 PM, in message [EMAIL PROTECTED], Joshua Slive [EMAIL PROTECTED] wrote: On 8/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: bnicholes Date: Tue Aug 1 15:54:38 2006 New Revision: 427780 URL: http://svn.apache.org/viewvc?rev=427780view=rev Log: Converted the reject directive to be definitive and enabled directory_merge to merge all of the authorization rules and logic. Can you explain how you do something like the following: Allow access from anywhere except IPs starting 10.2, but also allow access from the specific subnet 10.2.1. Joshua Good point, I have reverted the reject directive being definitive and determined that I can achieve the same thing through other means. As far as answering your question. You can do it now, this way: SatisfyAll reject ip 10.2 require ip 10.2.1 /SatisfyAll Brad
Re: mod_auth_pam 2.2.X
On 8/2/2006 at 9:01 AM, in message [EMAIL PROTECTED], Jason Keltz [EMAIL PROTECTED] wrote: I apologize in advance if this is not the right forum for this type of question -- if so, please accept my apology and let me know where I might address this problem... - The currently available version of mod_auth_pam for Apache 2.0.X series does not work with the new Apache 2.2.X authentication scheme when combined with basic authentication since mod_auth_pam doesn't register a provider. Surprisingly enough, I can't find any references on the web to people trying to use mod_auth_pam with Apache 2.2.X which surprises me. I was looking at how I might attempt to patch the current module to work with 2.2.X. I can't seem to find much documentation on the new aaa scheme in 2.2.X, but it doesn't look overly complicated to do when I look at say, mod_authn_file. You are right, there isn't much development documentation which covers converting an older auth module to the new authnz architecture. The best bet is to take the existing modules as examples. I'm confused by an aspect of the new 2.2.X authentication scheme which I was hoping someone might be able to help with. If I want to port the AuthPAM_Enabled on|off into the new module, where would it go? It looks like there should be a mod_authn_pam which just handles only the pam authentication, and then say, a mod_authz_pamgroup that handles the require group directive, but it isn't clear to me where the enable flag belongs? I looked through the modules that come with Apache. The only module that has an enable type flag seems to be the ldap module, yet all of the references to the enable flag are commented out in that code. I wonder why? Understand that I have not looked at the auth_pam module so I don't know exactly what all of the different configuration directives do. However it is highly likely that you do not even need the AuthPAM_Enabled directive any more. Under the new architecture, enabling or disabling an authn module is done my simply including it or excluding it from the AuthXXXProvider directive. Further, how about the AuthFailDelay, and AuthPAM_FallThrough? Would these go into mod_authn_pam as well? As far as I can see, mod_authz_pam doesn't seem necessary since the basic authentication covers the use of require user... I would guess that the only thing required is that you create a mod_authn_pam authentication module and that an authz_pam module is not needed. Unless you have the need to implement a very specialized type of authorization, you can simply rely on the existing authz modules to do the work. However, if you do need a specialized PAM group authorization for example, rather than implementing another 'Require group xxx' directive, you would need to implement a 'pam-group' authorization type. See mod_authnz_ldap or mod_authz_dbm as examples. Brad
Re: mod_auth_pam 2.2.X
On 8/2/2006 at 10:53 AM, in message [EMAIL PROTECTED], Jason Keltz [EMAIL PROTECTED] wrote: Brad Nicholes wrote: On 8/2/2006 at 9:01 AM, in message [EMAIL PROTECTED], Jason Keltz Understand that I have not looked at the auth_pam module so I don't know exactly what all of the different configuration directives do. However it is highly likely that you do not even need the AuthPAM_Enabled directive any more. Under the new architecture, enabling or disabling an authn module is done my simply including it or excluding it from the AuthXXXProvider directive. Actually, that makes a lot of sense. However, I have another similar difficulty. I had also added my own AuthPAMEngine command to mod_auth_pam that would only work from the server configuration. It is a very simple flag that could be toggled at the server level. This way, I could allow mod_auth_pam to be used on only specific virtual servers. I enabled it only in our SSL configuration. Could that also be integrated into the mod_authn_pam module? Is there a better way in Apache that permits the web site owner to restrict access to modules from within particular virtual servers? You could implement an AuthPAMEngine directive in mod_authn_pam but you would have to decide exactly what that means. Keep in mind that under the authnz architecture, every provider listed in a specific AuthnXXXProvider directive will be called and must return some kind of AUTH_XXX code. If a provider is not listed in a particular AuthnXXXProvider directive for a Directory or Location block, the provider will not be called for that block. So like I mentioned before, enabling or disabling it is simply a matter of including it in the AuthnXXXProvider directive or not. If you did implement an AuthPAMEngine directive, you would need to decide what 'AuthPAMEngine Off' means as far as which auth code should be returned. If you return an AUTH_DENIED then other authn providers that follow your authn_pam provider that are listed in the AuthnXXXProvider directive would be called and allowed to authenticate the user, otherwise the request would be denied. If you returned AUTH_GRANTED then only the authn providers that were listed previous to your authn_pam provider would have been called and authentication would stop at that point and granted. There isn't a DECLINED option anymore. Basically if your PAM provider is never included in any AuthnXXXProvider directive, then it is never called and is just dead code (ie, disabled). Brad
Re: svn commit: r427780 - in /httpd/httpd/trunk: docs/manual/mod/mod_authz_core.xml modules/aaa/mod_
On 8/2/2006 at 1:38 PM, in message [EMAIL PROTECTED], Ruediger Pluem [EMAIL PROTECTED] wrote: On 08/02/2006 12:54 AM, [EMAIL PROTECTED] wrote: Author: bnicholes Date: Tue Aug 1 15:54:38 2006 New Revision: 427780 URL: http://svn.apache.org/viewvc?rev=427780view=rev Log: Converted the reject directive to be definitive and enabled directory_merge to merge all of the authorization rules and logic. Modified: httpd/httpd/trunk/docs/manual/mod/mod_authz_core.xml httpd/httpd/trunk/modules/aaa/mod_auth.h httpd/httpd/trunk/modules/aaa/mod_authz_core.c Modified: httpd/httpd/trunk/docs/manual/mod/mod_authz_core.xml URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_authz_core .xml?rev=427780r1=427779r2=427780view=diff = = --- httpd/httpd/trunk/docs/manual/mod/mod_authz_core.xml (original) +++ httpd/httpd/trunk/docs/manual/mod/mod_authz_core.xml Tue Aug 1 15:54:38 2006 @@ -112,8 +112,8 @@ directivesynopsis nameReject/name -descriptionRejects which authenticated users can access -a resource/description +descriptionRejects authenticated users or host based +requests from accessing a resource/description syntaxReject varentity-name/var [varentity-name/var] .../syntax contextlistcontextdirectory/contextcontext.htaccess/context /contextlist @@ -122,10 +122,12 @@ usage pThis directive is similar to the directive module=mod_authz_coreRequire/directive directive however -it rejects which authenticated users can access a resource. The +it rejects which authenticated users or host based requests from accessing a resource. The restrictions are processed by authorization modules. See the directive module=mod_authz_coreRequire/directive directive for details -about usage./p +about usage. If found as part of the authorization rules, the reject directive +is definitive. In other words, if the reject statements is satisfied, the entire request +is automatically rejected no matter what other require rules may exist./p /usage seealsoa href=../howto/auth.htmlAuthentication, Authorization, @@ -220,6 +222,31 @@ seealsoa href=../howto/auth.htmlAuthentication, Authorization, and Access Control/a/seealso + +/directivesynopsis + +directivesynopsis type=section +nameAuthzMergeRules/name +descriptionSet to 'on' to allow the parent's lt;Directorygt; or lt;Locationgt; +authz rules to be merged into the current lt;Directorygt; or lt;Locationgt;. +Set to 'off' to disable merging. If set to 'off', only the authz rules defined in +the current lt;Directorygt; or lt;Locationgt; block will apply./description +syntaxAuthMergeRules on | off/syntax +defaultAuthMergeRules on/default +contextlistcontextdirectory/contextcontext.htaccess/context +/contextlist +overrideAuthConfig/override + +usage +pBy default all of the authorization rules within a lt;Directorygt; +lt;Locationgt; hierarchy are merged together to form a single +logical authorization operation. If AuthzMergeRules is set to 'on', then Shouldn't that be 'off' above? Regards Rüdige No, the default is to merge authz rules. At least that is how I understood access control to be working by default in the past. There was no concept of inherited authz before 2.3. Also, Joshua pointed out a flaw in my thinking which I am looking into now. Brad
Re: svn commit: r427780 - in /httpd/httpd/trunk: docs/manual/mod/mod_authz_core.xml modules/aaa/mod_
On 8/2/2006 at 3:39 PM, in message [EMAIL PROTECTED], Ruediger Pluem [EMAIL PROTECTED] wrote: On 08/02/2006 11:00 PM, Brad Nicholes wrote: No, the default is to merge authz rules. At least that is how I understood access control to be working by default in the past. There was no concept of inherited authz before 2.3. Also, Joshua pointed out a flaw in my thinking which I am looking into now. My bad I did not cite it correctly. I was not talking about the default, but the fact that on and off is explained differently in different sections (at least to my understanding): +Set to 'off' to disable merging. If set to 'off', only the authz rules defined in +the current lt;Directorygt; or lt;Locationgt; block will apply./description +syntaxAuthMergeRules on | off/syntax +defaultAuthMergeRules on/default +contextlistcontextdirectory/contextcontext.htaccess/context +/contextlist +overrideAuthConfig/override + +usage +pBy default all of the authorization rules within a lt;Directorygt; +lt;Locationgt; hierarchy are merged together to form a single +logical authorization operation. If AuthzMergeRules is set to 'on', then +only the authorization rules that are contained with the current +lt;Directorygt; or lt;Locationgt; block are considered. This First 'off' is said to prevent merging (which makes sense), but later on 'on' is said to do just that. Regards Rüdige Right, I got it now. Thanks Brad
Re: [VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP
On 7/27/2006 at 12:37 PM, in message [EMAIL PROTECTED], William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Chinese firedrill time folks. There is a vulnerability affecting mod_rewrite which this release addresses. See the recent commit activity for detail. Need your votes on the following in the usual http://httpd.apache.org/dev/dist/ +/-1 Package [ ] apache_1.3.37 [ ] httpd-2.0.59 [ ] httpd-2.2.3 Many thanks in advance, your humble RM, Bil +1 all NetWare Brad
Re: 401 response with reject ip?
On 7/26/2006 at 9:11 AM, in message [EMAIL PROTECTED],
Ruediger
Pluem [EMAIL PROTECTED] wrote:
On Mon, Jul 24, 2006 at 9:02 AM, in message
[EMAIL PROTECTED],
Well, I think that the following patch in mod_authz_core.c fixes
the
problem that you are looking at:
@@ -628,16 +633,25 @@
switch (auth_result) {
case AUTHZ_DENIED:
+case AUTHZ_NEUTRAL:
It seems that this patch is incomplete as AUTHZ_NEUTRAL is not
defined.
Furthermore doesn't mod_authz_host has to return AUTHZ_NEUTRAL?
Sorry, AUTHZ_NEUTRAL was part of a follow-on patch that I am working
on. It shouldn't have been part of this patch.
However, this brings up the question, what does reject actually
mean?
Require means that if true then authorization
is granted otherwise authorization is denied. Reject obviously
means that
if true, then authorization is denied but
it does not necessarily mean the opposite. So in the case that you
defined:
location /
reject ip 127.0.0.1
/location
obviously if the request is coming from 127.0.0.1 then the request
is
denied. But if the request comes from some other
ip address, is authorization automatically granted? I don't think
it is.
There still needs to be a Require statement
in the configuration somewhere.
It does give me access when I get there from an IP != 127.0.0.1
without any
further require directive. I don't know if this is works as designed
or a
bug.
At this point I consider it to be a bug. This is the patch that I am
currently working on that includes the use of AUTHZ_NEUTRAL return code.
I think that if the reject condition is satisfied then the request
should definitely be denied however I don't think that reject should
ever grant authorization. I think that the correct configuration for
your example should be
location /
require all granted
reject ip 127.0.0.1
/location
If you wanted it to work as it is now. This would basically be the
same as
location /
order allow,deny
deny from 127.0.0.1
/location
under 2.2 configuration syntax
Brad
Re: 401 response with reject ip?
On Mon, Jul 24, 2006 at 9:02 AM, in message [EMAIL PROTECTED],
Ruediger Pluem [EMAIL PROTECTED] wrote:
Having added the following to my virtual host
location /
reject ip 127.0.0.1
/location
results in a 401 response and the following entries in the error_log
[Mon Jul 24 16:56:03 2006] [error] [client 127.0.0.1] user (null):
authorization
failure for /:
[Mon Jul 24 16:56:03 2006] [error] [client 127.0.0.1] need AuthType to note
auth
failure: /
Either I did the configuration wrong or the result is wrong. I think I
should
get a 403 response instead and the message in the log should be something
like
[Mon Jul 24 16:47:49 2006] [error] [client 127.0.0.1] client denied by
server
configuration: /usr/src/apache/apache_2.0.x/htd
ocs/zw/formtest.html
Regards
Rüdiger
Well, I think that the following patch in mod_authz_core.c fixes the problem
that you are looking at:
@@ -628,16 +633,25 @@
switch (auth_result) {
case AUTHZ_DENIED:
+case AUTHZ_NEUTRAL:
/* XXX If the deprecated Satisfy directive is set to anything
but ANY a failure in access control or authz will cause
an HTTP_UNAUTHORIZED. Just the if statement
should be removed in 3.0 when the Satisfy directive
goes away. */
if (!note || (ap_satisfies(r) != SATISFY_ANY) || (note[0] ==
'N')) {
-ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
- user %s: authorization failure for \%s\:
,
- r-user, r-uri);
-return_code = HTTP_UNAUTHORIZED;
+if (r-ap_auth_type == NULL) {
+ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ client denied by server configuration:
%s,
+ r-filename);
+return_code = HTTP_FORBIDDEN;
+}
+else {
+ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ user %s: authorization failure for
\%s\: ,
+ r-user, r-uri);
+return_code = HTTP_UNAUTHORIZED;
+}
}
else {
return_code = DECLINED;
However, this brings up the question, what does reject actually mean?
Require means that if true then authorization is granted otherwise
authorization is denied. Reject obviously means that if true, then
authorization is denied but it does not necessarily mean the opposite. So in
the case that you defined:
location /
reject ip 127.0.0.1
/location
obviously if the request is coming from 127.0.0.1 then the request is denied.
But if the request comes from some other ip address, is authorization
automatically granted? I don't think it is. There still needs to be a
Require statement in the configuration somewhere.
Brad
Re: svn commit: r411306 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c
Graham Leggett [EMAIL PROTECTED] 6/4/2006 2:42 AM Brad Nicholes wrote: Should we define our own macro which uses LDAP_SECURITY_ERROR or the more detailed logic, to keep the mainline code cleaner and support reuse in other paths I thought about that and couldn't really decide if we should define the LDAP_SECURITY_ERROR macro in the ldap header in apr-util or not. I finally decided that if we started down that road then there are probably a lot more macros and other differences between the LDAP SDKs and how far should we take it. So rather than try to redefine all of the missing macros and force a dependancy on between httpd and apr-util, I would just solve it in authnz_ldap. We could certainly rethink this and try to solve it in apr-util instead. apr_util already defines a number of macros for the purposes of standardising them, particularly for the SSL/TLS stuff where every LDAP toolkit insisted on doing it differently, so we have already gone down that road. Standardising the macros is one thing that apr_util helps with to make LDAP access toolkit independent. The best solution IMHO is to add APU_LDAP_something to apr_util depending on how the different toolkits handle LDAP_SECURITY_ERROR (Does this macro mean security error?). Will have to look at the different toolkits to work out what something should be. In the mean time though the patch is reasonable as is, it can be changed once apr_util is patched and another apr_util is released. Regards, Graham -- +1, I'll add a new macro to apr-util and call it APU_LDAP_SECURITY_ERROR. With the patch that is currently in place in authnz_ldap, we can add the APU macros now and then remove the authnz_ldap patch at a latter time once a new APR-Util has been released. I think the basic differences between the SDKs is whether the macro exists or not. Also from what I could see, there seemed to be a naming difference between the Microsoft SDK and the others with the #define LDAP_INSUFFICIENT_RIGHTS vs. LDAP_INSUFFICIENT_ACCESS. This can be easily handled in the APU macro as well. Brad
Re: svn commit: r411306 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c
On 6/3/2006 at 5:45 AM, in message [EMAIL PROTECTED], Jeff Trawick [EMAIL PROTECTED] wrote: On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: bnicholes Date: Fri Jun 2 15:01:53 2006 New Revision: 411306 URL: http://svn.apache.org/viewvc?rev=411306view=rev Log: Fix a problem with invalid auth error detection for LDAP client SDKs that don't support LDAP_SECURITY_ERROR macro. PR#39529 Should we define our own macro which uses LDAP_SECURITY_ERROR or the more detailed logic, to keep the mainline code cleaner and support reuse in other paths I thought about that and couldn't really decide if we should define the LDAP_SECURITY_ERROR macro in the ldap header in apr-util or not. I finally decided that if we started down that road then there are probably a lot more macros and other differences between the LDAP SDKs and how far should we take it. So rather than try to redefine all of the missing macros and force a dependancy on between httpd and apr-util, I would just solve it in authnz_ldap. We could certainly rethink this and try to solve it in apr-util instead. Brad
RE: Authentication Bug? (Patch?)
Which LDAP client library are you linking with and what version is
it. The problem is that your client library apparently doesn't support
the LDAP_SECURITY_ERROR macro. This macro basically does what your
patch is doing except that it looks at the complete range of possible
security related failures. The macro is defined as
#define LDAP_RANGE(n,x,y) (((x) = (n)) ((n) = (y)))
#define LDAP_SECURITY_ERROR(n) LDAP_RANGE((n),0x30,0x32) /* 48-50 */
I know that both OpenLDAP and Novell LDAP support this macro.
Brad
On 6/2/2006 at 11:03 AM, in message
[EMAIL PROTECTED],
Fenlason,
Josh [EMAIL PROTECTED] wrote:
I made the following patch to mod_authnz_ldap.c and it fixed my
issue.
Does any one have any comments? Any chance this could be committed?
Anything else I need to do? Thanks.
,
Josh.
*** mod_authnz_ldap.c Fri Apr 21 20:53:05 2006
--- mod_authnz_ldap.c.patch Fri Jun 02 11:48:41 2006
***
*** 409,415
[% APR_PID_T_FMT ] auth_ldap authenticate:
user %s authentication failed; URI %s
[%s][%s],
getpid(), user, r-uri, ldc-reason,
ldap_err2string(result));
!
return (LDAP_NO_SUCH_OBJECT == result) ?
AUTH_USER_NOT_FOUND
#ifdef LDAP_SECURITY_ERROR
: (LDAP_SECURITY_ERROR(result)) ? AUTH_DENIED
--- 409,417
[% APR_PID_T_FMT ] auth_ldap authenticate:
user %s authentication failed; URI %s
[%s][%s],
getpid(), user, r-uri, ldc-reason,
ldap_err2string(result));
! if ( LDAP_INVALID_CREDENTIALS == result ) {
! return AUTH_DENIED; // user provided invalid
credentials.
deny them so they can retry
! }
return (LDAP_NO_SUCH_OBJECT == result) ?
AUTH_USER_NOT_FOUND
#ifdef LDAP_SECURITY_ERROR
: (LDAP_SECURITY_ERROR(result)) ? AUTH_DENIED
From: Fenlason, Josh
Sent: Friday, June 02, 2006 10:07 AM
To: 'dev@httpd.apache.org'
Subject: Authentication Bug?
I'm trying to move to Apache 2.2.2 and I'm running into some
authentication troubles.
When I enter the correct username/password it authenticates
properly. When I enter an invalid username, I get prompted up to
three
times and it fails with a 401 like expected. My problem is when I
attempt to authenticate with a valid username and provide an invalid
password. It fails with a 500 error and this message is in the
error
log [3692] auth_ldap authenticate: user admin authentication
failed;
URI / [ldap_simple_bind_s() to check user credentials
failed][Invalid
Credentials]. It only prompts me once. If I don't enter the
correct
password, it fails for the browser session.
I'm not the only one experiencing this issue, see the thread on
the user list
(http://marc.theaimsgroup.com/?l=apache-httpd-usersm=114910962114624w=
2).
Is there something wrong with my configuration? If not, I can
open a bug. In my opinion this would be a pretty serious regression
from Apache 2.0.x (hopefully I'm just missing something obvious
though).
,
Josh.
Here's my authentication configuration:
AuthnProviderAlias ldap test
AuthLDAPURL ldap://localhost/ou=people
ldap://localhost/ou=people
/AuthnProviderAlias
Location /
AuthzLDAPAuthoritative off
AuthName Test
AuthType Basic
AuthBasicProvider test
require valid-user
/Location
RE: Authentication Bug? (Patch?)
There has already been a bug submitted on this one PR#39529. I have
committed the patch in trunk and proposed it for backport.
Brad
On 6/2/2006 at 11:59 AM, in message
[EMAIL PROTECTED],
Fenlason,
Josh [EMAIL PROTECTED] wrote:
I'm building with iPlanet (v 5.08) on Unix and the Microsoft LDAP SDK
on
Windows. iPlanet is listed as a working SDK and 5.08 is the latest
that
I know of. What about including my patch if the LDAP library
doesn't
support LDAP_SECURITY_ERROR? If LDAP_SECURITY_ERROR isn't defined,
then
include my patch. Thanks.
,
Josh.
-Original Message-
From: Brad Nicholes [mailto:[EMAIL PROTECTED]
Sent: Friday, June 02, 2006 12:38 PM
To: dev@httpd.apache.org
Subject: RE: Authentication Bug? (Patch?)
Which LDAP client library are you linking with and what
version is it. The problem is that your client library
apparently doesn't support the LDAP_SECURITY_ERROR macro.
This macro basically does what your patch is doing except
that it looks at the complete range of possible security
related failures. The macro is defined as
#define LDAP_RANGE(n,x,y)(((x) = (n)) ((n) = (y)))
#define LDAP_SECURITY_ERROR(n)
LDAP_RANGE((n),0x30,0x32) /* 48-50 */
I know that both OpenLDAP and Novell LDAP support this macro.
Brad
On 6/2/2006 at 11:03 AM, in message
[EMAIL PROTECTED],
Fenlason,
Josh [EMAIL PROTECTED] wrote:
I made the following patch to mod_authnz_ldap.c and it fixed my
issue.
Does any one have any comments? Any chance this could be
committed?
Anything else I need to do? Thanks.
,
Josh.
*** mod_authnz_ldap.c Fri Apr 21 20:53:05 2006
--- mod_authnz_ldap.c.patch Fri Jun 02 11:48:41 2006
***
*** 409,415
[% APR_PID_T_FMT ] auth_ldap
authenticate:
user %s authentication failed; URI %s
[%s][%s],
getpid(), user, r-uri, ldc-reason,
ldap_err2string(result)); !
return (LDAP_NO_SUCH_OBJECT == result) ?
AUTH_USER_NOT_FOUND
#ifdef LDAP_SECURITY_ERROR
: (LDAP_SECURITY_ERROR(result)) ? AUTH_DENIED
--- 409,417
[% APR_PID_T_FMT ] auth_ldap
authenticate:
user %s authentication failed; URI %s
[%s][%s],
getpid(), user, r-uri, ldc-reason,
ldap_err2string(result));
! if ( LDAP_INVALID_CREDENTIALS == result ) {
! return AUTH_DENIED; // user provided invalid
credentials.
deny them so they can retry
! }
return (LDAP_NO_SUCH_OBJECT == result) ?
AUTH_USER_NOT_FOUND
#ifdef LDAP_SECURITY_ERROR
: (LDAP_SECURITY_ERROR(result)) ? AUTH_DENIED
From: Fenlason, Josh
Sent: Friday, June 02, 2006 10:07 AM
To: 'dev@httpd.apache.org'
Subject: Authentication Bug?
I'm trying to move to Apache 2.2.2 and I'm running into some
authentication troubles.
When I enter the correct username/password it
authenticates properly.
When I enter an invalid username, I get prompted up to
three
times and it fails with a 401 like expected. My problem is when I
attempt to authenticate with a valid username and provide
an invalid
password. It fails with a 500 error and this message is in the
error
log [3692] auth_ldap authenticate: user admin authentication
failed;
URI / [ldap_simple_bind_s() to check user credentials
failed][Invalid
Credentials]. It only prompts me once. If I don't enter the
correct
password, it fails for the browser session.
I'm not the only one experiencing this issue, see the
thread on the
user list
(http://marc.theaimsgroup.com/?l=apache-httpd-usersm=11491096
2114624w=
2).
Is there something wrong with my configuration? If
not, I can open a
bug. In my opinion this would be a pretty serious regression from
Apache 2.0.x (hopefully I'm just missing something obvious
though).
,
Josh.
Here's my authentication configuration:
AuthnProviderAlias ldap test
AuthLDAPURL ldap://localhost/ou=people
ldap://localhost/ou=people
/AuthnProviderAlias
Location /
AuthzLDAPAuthoritative off
AuthName Test
AuthType Basic
AuthBasicProvider test
require valid-user
/Location
Re: [VOTE] Apache HTTP Server 1.3.36 Candidate
On 5/14/2006 at 7:34 AM, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Please test and vote on releasing Apache httpd 1.3.36 Download from: http://httpd.apache.org/dev/dist/ Changes: http://httpd.apache.org/dev/dist/CHANGES_1.3 MD5s: MD5 (apache_1.3.36.tar.Z) = 2c310916fb97a9d4d700d8b8fad29423 MD5 (apache_1.3.36.tar.gz) = d6c0709fc1f20d6d93d30435fcfc4843 (NOTE: http://people.apache.org/~jim/apache_1.3.36/ is also a valid URL to use until httpd.apache.org syncs with people.apache.org) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http:// www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball. +1 NetWare Brad
Re: [VOTE] 2.0.58 Candidate
On 4/24/2006 at 12:40:58 pm, in message [EMAIL PROTECTED], Colm MacCarthaigh [EMAIL PROTECTED] wrote: O.k., for the last time, hopefully :) A candidate for 2.0.58 is available for testing and voting at; http://httpd.apache.org/dev/dist/ The MD5sums are; ac732a8b3ec5760baa582888f5dbad66 httpd-2.0.58.tar.bz2 a03eeefee78c01ec24c8671380763860 httpd-2.0.58.tar.gz The code is identical to the previous 2.0.57 candidate save the ap_release.h version numver change. The only material change is the revert of the copyright years. I don't remember if I voted on this one already or not :/ +1 NetWare Brad
Re: [VOTE] 2.2.2 Candidate
On 4/21/2006 at 10:35:23 pm, in message [EMAIL PROTECTED], Paul Querna [EMAIL PROTECTED] wrote: Please test and vote on releasing httpd 2.2.2, bundling APR and APR-Util 1.2.7. Download from: http://httpd.apache.org/dev/dist/ Changes: http://httpd.apache.org/dev/dist/CHANGES_2.2 MD5s: 9c759a9744436de6a6aa2ddbc49d6e81 httpd-2.2.2.tar.bz2 a0d9f7f6f70110a5965340eb7f3a3e66 httpd-2.2.2.tar.gz Thanks, -Paul +1 NetWare Brad
Re: [VOTE] 2.0.57 candidate
On 4/19/2006 at 10:59:48 am, in message [EMAIL PROTECTED], Colm MacCarthaigh [EMAIL PROTECTED] wrote: Candidate tarballs for 2.0.57 are now available for testing/voting at; http://httpd.apache.org/dev/dist/ This doesn't include a changed notice-of-license text though, which is a potential open issue. +1 NetWare Brad
Re: [VOTE] 2.0.56 candidate
On 4/16/2006 at 2:53:24 pm, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: There are some 2.0.56 candidate tarballs now at; http://httpd.apache.org/dev/dist/ available for review/voting. Major apologies to wrowe for toe-stepping here, I'd missed some communications and then only caught up after doing stuff anyway. +1 NetWare Brad
Re: [VOTE] Release 2.2.1 as GA
On 4/1/2006 at 12:28 pm, in message [EMAIL PROTECTED], Paul Querna [EMAIL PROTECTED] wrote: 2.2.1, embedding APR 1.2.6 and APR-Util 1.2.6, is available from: http://httpd.apache.org/dev/dist/ Please Test and Vote on releasing 2.2.1 as GA. MD5s: f330230636926d08872d84343b08fa16 httpd-2.2.1.tar.bz2 63e7f3e24adda0888a48a247b4eb5613 httpd-2.2.1.tar.gz Thanks, Pau -1 NetWare Generating Release.o\Apache2_link.opt Linking Release.o/Apache2.nlm ### mwldnlm Linker Error: # Undefined symbol: apu_version_string in # main.o Errors caused tool to abort. gmake: *** [Release.o/Apache2.nlm] Error 1 Seems we have the same missing apu_version_string problem Brad
Re: [VOTE] Release 2.2.1 as GA
On 4/3/2006 at 8:54:29 am, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: On 4/1/2006 at 12:28 pm, in message [EMAIL PROTECTED], Paul Querna [EMAIL PROTECTED] wrote: 2.2.1, embedding APR 1.2.6 and APR-Util 1.2.6, is available from: http://httpd.apache.org/dev/dist/ Please Test and Vote on releasing 2.2.1 as GA. MD5s: f330230636926d08872d84343b08fa16 httpd-2.2.1.tar.bz2 63e7f3e24adda0888a48a247b4eb5613 httpd-2.2.1.tar.gz Thanks, Pau -1 NetWare Generating Release.o\Apache2_link.opt Linking Release.o/Apache2.nlm ### mwldnlm Linker Error: # Undefined symbol: apu_version_string in # main.o Errors caused tool to abort. gmake: *** [Release.o/Apache2.nlm] Error 1 Seems we have the same missing apu_version_string problem Brad SVN rev. 391070 resolves the issue for NetWare. Brad
Re: apu_version mess
On 4/3/2006 at 11:38:28 am, in message [EMAIL PROTECTED], William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Paul Querna wrote: To resolve the problems we have with calling apu_version from httpd, we have three main options: [ ] Remove the new code that outputted the versions. [ ] Make the code only present on systems that didn't have a broken build. [X] Wait for APR-Util 1.2.7 to be released. ... as a bugfix (configuration) release only, and quickly? yes. Votes/Thoughts? All of the options pretty much mean scraping the 2.2.1 release, and moving on to 2.2.2. Previous to 1.2.7 Win32 and Netware were borked. FYI I'm doing a fast delta on win32/unix (Brad, could you shoot me th My vote would be first Wait for APR-Util 1.2.7 to be released if this can happen quickly. Even if the only difference between 1.2.6 and 1.2.7 is the apu_version_string() patch for Win32/NetWare. Otherwise I would go with Remove the new code that outputted the versions Brad
Re: [mod_auth_ldap] filter enhancement
On 3/24/2006 at 2:56:01 am, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Hi everybody, I would like to enhance this module to be able to match the username in more than one attribut in an OR condition. Currently, this module uses the AuthLDAPURL: AuthLDAPURL ldap://server/searchbase?attribute_containing_the_login?scope?additionnal_fi lter it constructs the filter like this: ((attribute_containing_the_login=provided_login)(additionnal_filter)) but I think it could be usefull (I need it now ;)) to have more than one attribute_containing_the_login. I see to way for doing this: Permit multiple attributes separated by comma in place of attribute_containing_the_login, as stated in RFC 2255. resulting filter wille be: ((|(attr1=provided_login)(attr2=provided_login)(...))(additionnal_filter)) Or Permit to not provide attribute_containing_the_login but replace any occurence of for example %u in the additionnal_filter by the provided login. I'm okay to provide a patch, but I would like to know your opinion on those 2 way. Submit a patch and let's take a look at what you are proposing. Keep in mind that the LDAP URL that mod_authnz_ldap consumes, already allow you to enter multiple comma delimited attributes as described by RFC 2255. However mod_authnz_ldap only recognizes the first attribute as the search attribute. All of the other listed attributes including the search attribute are used to extract the values as part of the request. Changing the format of the filter based on the attribute list in the LDAP URL would change the searching behavior without the administrator knowing that it happened. This could be very bad because just upgrading to a new version of mod_authnz_ldap and restarting Apache could completely change the way authentication is working. I would suggest that you go with your second proposal. That would provide the same type of functionality but without the upgrade surprise. Brad
Re: Appeal for help understanding fiendishly complex data structure in mod_authz_core
{ On 3/19/2006 at 8:40:56 am, in message [EMAIL PROTECTED],
[EMAIL PROTECTED]
wrote:
mod_authz_core contains a fiendishly complex data structure, the
'authz_provider_list' (which is actually more like a tree than a list),
which is used to implement the concept of nested
SatisfyOne/SatisfyAll sections.
I've been trying off-and-on for about a week to understand this
structure, and the code that creates and walks it, but have been
unsuccessful.
I'm sending this email as an appeal for assistance understanding this
code, and also as an alert that this code may prove to be a potential
maintenance problem, if it is so difficult to comprehend.
Thanks,
Max.
You are right, the piece of code that traverses the SatisfyOne/All list is a
bit complex which is the reason why I tried to document it well according to
what the code is doing. If I could have made this code simpler, obviously I
would have. The basic concept behind the code as I see it, is a list that
grows horizontally or vertically with each nested state change (ie. one vs
all). The only other component that is tracked while the list (or tree) is
being traversed is the nesting level. The nesting level simply indicates how
many state changes have occurred within a given path from the root node to the
leaf node. I'm not sure that I can explain the code much better through an
email than is already explained in the comments and source code that exist in
the add_authz_provider() or check_provider_list() functions. When adding a
node to the list, the idea is to follow the nesting path until a leaf node is
encountered and then add the new node to the leaf node depending on whether the
new node maintains the same state or introduces a state change. When checking
the provider list, each provider in the list must be satisfied according to
it's state and boolean logic.
Brad
Re: svn commit: r386776 - in /httpd/httpd/trunk/docs/manual/mod:mod_ldap.html.en mod_ldap.xml
Graham Leggett [EMAIL PROTECTED] 3/18/2006 3:58:42 am [EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewcvs?rev=386776view=rev Log: LDAPConnectionTimeout and LDAPVerifyServerCert can be configured per-vhost We need to note in addition to this that not all LDAP SDK libraries support the concept of separately configurable verify server cert behaviour. In other words, even though you specify LDAPVerifyServerCert in LDAP connections from vhost A, you end up overriding this when you specify it in vhost B. This affects people using the Novell SDK. I think putting a note in the directive pointing people to http://httpd.apache.org/docs/2.2/mod/mod_ldap.html#settingcerts will save some questions on mailing lists. Regards, Graham -- Now that you mention it, allowing LDAPVerifyServerCert and LDAPConnectionTimeout to be overwritten in a vhost is still wrong. According to the code, none of the SDKs support setting verify server cert on a per-connection basis, therefore GLOBAL_ONLY needs to be put back on this directive and vhost merging needs to be modify to reflect that. The connection time out appears to be supported per-connection for the OpenLDAP SDK but the Novell LDAP SDK only supports it on a global basis. I would suggest that we make LDAPConnectionTimeout GLOBAL_ONLY also since having the ability to set the timeout on a vhost basis has little value anyway. Brad
Re: svn commit: r386698 - /httpd/httpd/trunk/modules/ldap/util_ldap.c
On 3/17/2006 at 12:53 pm, in message
[EMAIL PROTECTED], Jeff
Trawick
[EMAIL PROTECTED] wrote:
On 3/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: bnicholes
Date: Fri Mar 17 11:26:27 2006
New Revision: 386698
URL: http://svn.apache.org/viewcvs?rev=386698view=rev
Log:
Fix the server_merge so that the memory pools and mutexes that were
created
during the server_create, are used. Allow the settings that can be
overwritten in a vhost to use the vhost values
Modified:
httpd/httpd/trunk/modules/ldap/util_ldap.c
Modified: httpd/httpd/trunk/modules/ldap/util_ldap.c
URL:
http://svn.apache.org/viewcvs/httpd/httpd/trunk/modules/ldap/util_ldap.c?rev=
386698r1=386697r2=386698view=diff
=
=
--- httpd/httpd/trunk/modules/ldap/util_ldap.c (original)
+++ httpd/httpd/trunk/modules/ldap/util_ldap.c Fri Mar 17 11:26:27
2006
@@ -1753,24 +1753,36 @@
util_ldap_state_t *base = (util_ldap_state_t *) basev;
util_ldap_state_t *overrides = (util_ldap_state_t *)
overridesv;
-st-pool = base-pool;
+st-pool = overrides-pool;
#if APR_HAS_THREADS
-st-mutex = base-mutex;
+st-mutex = overrides-mutex;
#endif
+/* The cache settings can not be modified in a
+virtual host since all server use the same
+shared memory cache. */
st-cache_bytes = base-cache_bytes;
st-search_cache_ttl = base-search_cache_ttl;
st-search_cache_size = base-search_cache_size;
st-compare_cache_ttl = base-compare_cache_ttl;
st-compare_cache_size = base-compare_cache_size;
-st-connections = base-connections;
-st-ssl_supported = base-ssl_supported;
+
+st-connections = NULL;
+st-ssl_supported = 0;
st-global_certs = apr_array_append(p, base-global_certs,
overrides-global_certs);
st-client_certs = apr_array_append(p, base-client_certs,
overrides-client_certs);
st-secure = (overrides-secure_set == 0) ? base-secure
: overrides-secure;
+
+/* LDAP connection settings can be overwritten in a virtual
host */
+st-connectionTimeout = (overrides-connectionTimeout == 10)
+? base-connectionTimeout
+: overrides-connectionTimeout;
actually, it can't...
util_ldap_set_connection_timeout() has
err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
if (err != NULL) {
return err;
}
should I remove that check for GLOBAL_ONLY?
I can a check for GLOBAL_ONLY and try to update the docs for
directives that aren't appropriate in a vhost, according to your
notes
in the merge function
Ah crap, I knew I was missing something that was preventing the
directives from being called in a vhost. The GLOBAL_ONLY should be
removed from the LDAPConnectionTimeout directive. In fact I probably
need to add GLOBAL_ONLY to all of the caching directives even though
nothing would happen even if somebody tried to set a cache directive
inside a vhost.
Brad
Re: pool use/mutex initialization in util_ldap not thread safe?
On 3/16/2006 at 7:12 am, in message [EMAIL PROTECTED], Jeff Trawick [EMAIL PROTECTED] wrote: On 3/16/06, Ruediger Pluem [EMAIL PROTECTED] wrote: On 03/16/2006 03:49 AM, Jeff Trawick wrote: On 3/15/06, Brad Nicholes wrote: That is really one pool globally but there is a mutex per server_rec. So a thread handling a request for one vhost grabs the mutex and uses the pool but that doesn't protect from a thread handling a request for a different vhost which grabs a different mutex supposedly protecting the same pool. Would it help to create sub-pools per server_rec from the config pool? That sounds like a definite improvement, but I'm eager for LDAP gurus to explain how pool growth is mitigated in the current design (assuming thread safety) before jumping to a conclusion The use of the pool is actually fairly limited. It is used to create and initialize the reusable LDAP resources such as ldap connections. The pool of ldap connections can grow but that is based on the amount of traffic that requires LDAP authentication. Even under very heavy use, the number of connections in the connection pool might be ~20 but even that is a generous number. Any per-request memory allocations are done from the request pool. So the potential for collisions within the global memory pool, although not 0, would be very low. The purpose of the mutex is not necessarily to protect the memory pool but to protect the ldap connection pool. Whenever mod_ldap needs to pull a connection from the ldap connection pool, it first grabs the mutex so that it is free to search for a connection and modify its parameters without having to worry about other threads doing the same thing. Since most of the global memory pool usage, outside of module initialization, also occurs after the connection pool mutex has been locked, this also lessens the chance of memory pool collisions. However, given all of there, I still think that there are things that need to be cleaned up especially with the mutex allocation and use in a worker MPM environment. Brad
Re: authz module source compatibility 2.2 - 2.3
{ On 3/16/2006 at 9:19 am, in message [EMAIL PROTECTED],
Max Bowsher
[EMAIL PROTECTED] wrote:
What is the expected level of source compatibility for authz modules
between 2.2 and 2.3?
I'm confused, as some parts of the authz framework on trunk seem to
be
attempting to allow some compatibility, whilst other parts do not.
Clarification would be welcome, as I'd like to write some patches for
the authz code, but don't want to do unnecessary work upholding
compatibility that isn't actually intended, or produce flawed patches
which decrease compatibility.
Thanks,
Max.
It is less than going from 2.0 - 2.2. Authn modules will need to be
recompiled but should not need to be patched. Authz modules on the
other hand will need to be converted from hook based to provider based.
You can see the work that would need to be done to an Authz module by
comparing a 2.2 authz module source with one from trunk. As far as
compatibility goes, authz functionality remains the same but the module
architecture is different.
Brad
Re: authz module source compatibility 2.2 - 2.3
{ On 3/16/2006 at 10:26 am, in message [EMAIL PROTECTED],
Max Bowsher
[EMAIL PROTECTED] wrote:
Thankyou. In light of this clarification, I have a further question:
is
there any reason why mod_authz_default should not be folded into
mod_authz_core?
It could be, but it remains separate for several reasons. First,
mod_authz_default could disappear in 3.0. Much of its purpose is to
bridge the gap between the 2.2/2.0 access control (ie. satisfy
directive) and the 2.3 access control (require directive). Second, both
modules need to hook the same auth_checker hook but at different times
and they also provide a different set of directives. Third, since there
is a mod_authn_default, maintaining a mod_authz_default seems more
consistent. Both mod_authz_core and mod_authz_default provide different
sets of functionality. Merging them would be more like implementing two
modules within the same .c file rather than merged functionality.
Brad
Re: pool use/mutex initialization in util_ldap not thread safe?
On 3/16/2006 at 11:34 am, in message [EMAIL PROTECTED], Jeff Trawick [EMAIL PROTECTED] wrote: On 3/16/06, Brad Nicholes [EMAIL PROTECTED] wrote: On 3/16/2006 at 7:12 am, in message [EMAIL PROTECTED], Jeff Trawick [EMAIL PROTECTED] wrote: On 3/16/06, Ruediger Pluem [EMAIL PROTECTED] wrote: On 03/16/2006 03:49 AM, Jeff Trawick wrote: On 3/15/06, Brad Nicholes wrote: That is really one pool globally but there is a mutex per server_rec. So a thread handling a request for one vhost grabs the mutex and uses the pool but that doesn't protect from a thread handling a request for a different vhost which grabs a different mutex supposedly protecting the same pool. Would it help to create sub-pools per server_rec from the config pool? That sounds like a definite improvement, but I'm eager for LDAP gurus to explain how pool growth is mitigated in the current design (assuming thread safety) before jumping to a conclusion The use of the pool is actually fairly limited. It is used to create and initialize the reusable LDAP resources such as ldap connections. The pool of ldap connections can grow but that is based on the amount of traffic that requires LDAP authentication. Even under very heavy use, the number of connections in the connection pool might be ~20 but even that is a generous number. if ldap server times out the connection and we have to bring one back up, that is no pool growth, right? we just get pool growth when we talk to an LDAP server we haven't already talked to yet, or when? No, there is no growth there. The cached or pooled information that consumes memory, remains the same. So there is no need to allocate more memory. If a connection times out or is broken for whatever reason, it is just the connection that needs to be re-established given all of the information that currently exists. Also the growth does just occur when we start talking to a new LDAP server. It occurs when we run out of connections to an LDAP server and require a new one. This may involve more than one LDAP server but in most cases it is just multiple connections to the same LDAP server. Any per-request memory allocations are done from the request pool. So the potential for collisions within the global memory pool, although not 0, would be very low. very low == still broken but much much harder to debug than high Right which is why I believe that there is work to be done here. The purpose of the mutex is not necessarily to protect the memory pool but to protect the ldap connection pool. Whenever mod_ldap needs to pull a connection from the ldap connection pool, it first grabs the mutex so that it is free to search for a connection and modify its parameters without having to worry about other threads doing the same thing. Since most of the global memory pool usage, outside of module initialization, also occurs after the connection pool mutex has been locked, this also lessens the chance of memory pool collisions. However, given all of there, I still think that there are things that need to be cleaned up especially with the mutex allocation and use in a worker MPM environment. I interpret this as meaning that the following would resolve the problems (race condition for mutex initialization between multiple threads for the same vhost and race condition for pool use between multiple threads in different vhosts): 1) this code needs LDAP-specific subpool of pchild* for each LDAP-enabled vhost, initialized in child-init hook 2) the vhost-specific mutex is initialized in the child-init hook (walk the server_rec list) *do these objects need to get cleaned up when the process goes away? maybe it shouldn't be a subpool at all but instead a freestanding pool (I can't remember at the moment if a freestanding pool keeps it from being cleaned up at child process exit) or 1) one global subpool of pchild* for each LDAP-enabled vhost, initialized in child-init hook 2) one global mutex initialized in the child-init hook It just depends on expected collision rate. I see some pthread_mutex_trylock usage, which makes me think the collision rate can be high, but it is unclear that segregating by vhost makes much of an improvement I am still looking at the code, but my gut feel is that child-init may not be the best place to create the pool or the mutex. All of this is vhost based and should remained separated in that way. Another problem is that memory allocations need to occur during config time which happens before child-init gets called. Brad
Re: svn commit: r386477 - /httpd/httpd/trunk/modules/ldap/util_ldap.c
On 3/16/2006 at 7:01 pm, in message [EMAIL PROTECTED], Jeff Trawick [EMAIL PROTECTED] wrote: On 3/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewcvs?rev=386477view=rev Log: remove the race condition when creating the connection pool mutex. Also eliminate some unnecessary uses of the global memory pool cool! @@ -1753,7 +1753,10 @@ util_ldap_state_t *base = (util_ldap_state_t *) basev; util_ldap_state_t *overrides = (util_ldap_state_t *) overridesv; -st-pool = p; +st-pool = base-pool; +#if APR_HAS_THREADS +st-mutex = base-mutex; +#endif What this use of the base pool and mutex means is that while a subpool and mutex were created for the vhost, we'll never use them. Instead, we'll use the subpool and mutex created for the main server. Not what you meant, right I guess I don't understand. When I tested this using the worker MPM (3 servers, 25 threads each) and configuring both an ldap protected directory in the main server and an ldap protected directory in a vhost, it never had a problem locking the mutex or allocating memory. Am I missing something? Brad
Re: pool use/mutex initialization in util_ldap not thread safe?
On 3/15/2006 at 2:34 pm, in message [EMAIL PROTECTED], Jeff Trawick [EMAIL PROTECTED] wrote: Plz forgive any misunderstanding, as well as my use of 2.0 function names ;) Also, for being slow at learning what ldap stands for. I know this code has been hashed over many many times over the last few years. util_ldap_create_config() creates the per-server config for util_ldap. That saves a config-time pool in the per-server config. util_ldap_connection_find() is called on a request and allocates a mutex using st-pool without holding a mutex, if the mutex wasn't created before. IOW, the first very-small-number of threads in that process that try to find a connection will allocate a mutex. Hopefully very-small-number is one (This is exactly the type of bug I had the displeasure of diagnosing in a proprietary module some time back; somebody eons ago had deferred some initialization until the first request, assuming incorrectly that there was no way that at the time of the first request for a certain vhost that there would actually be 2+ concurrent requests stomping on each other. one of the baby bells proved otherwise continually until the problem was found and fixed) The child init hook really needs to talk the server_recs and create the mutex there, right? Also, is the pool growth of the config-time pool reasonable? What happens when some other module cheats and uses a config-time pool on request processing thread, even if it is smart enough to protect the pool misuse with a mutex? (kaboom) If it is reasonable to grow some pool over time during the request processing, shouldn't it be an ldap-unique pool I think you are right. I am going to take a closer look at that code and see about fixing both the mutex problem and the use of the config pool. This could actually explain some funny things that I have been seeing on the NetWare build lately. Brad
[PATCH] Re: mod_authz_core:check_provider_list bug?
On 3/9/2006 at 4:49:24 am, in message [EMAIL PROTECTED],
Max Bowsher
[EMAIL PROTECTED] wrote:
Joe Orton wrote:
Found by the Coverity report, this one looks like a real bug:
check_provider_list has a if() branch to handle the passed-in
current_provider being NULL, but never sets it to anything else;
current_provider is later dereferenced unconditionally.
It looks like the authn-provider implementation was cloned to
produce
starting point of the authz-provider implementation, and this code
wasn't removed when it became redundant.
All callers of check_provider_list() ensure that they pass a
non-NULL
current_provider. The AUTHZ_DEFAULT_PROVIDER that is being looked up
in
this code is never registered. The no-providers-configured case is
dealt with in authorize_user(), before check_provider_list() is ever
called.
I suggest the following patch:
[[[
* modules/aaa/mod_authz_core.c (check_provider_list):
Remove redundant code.
* modules/aaa/mod_auth.h (AUTHZ_DEFAULT_PROVIDER):
Remove redundant definition.
]]]
[[[
Index: modules/aaa/mod_authz_core.c
===
--- modules/aaa/mod_authz_core.c(revision 384494)
+++ modules/aaa/mod_authz_core.c(working copy)
@@ -482,28 +482,10 @@
const authz_provider *provider;
-/* For now, if a provider isn't set, we'll be nice and use the
file
- * provider.
- */
-if (!current_provider) {
-provider = ap_lookup_provider(AUTHZ_PROVIDER_GROUP,
- AUTHZ_DEFAULT_PROVIDER, 0);
+provider = current_provider-provider;
+apr_table_setn(r-notes, AUTHZ_PROVIDER_NAME_NOTE,
+ current_provider-provider_name);
-if (!provider || !provider-check_authorization) {
-ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
- No default authz provider configured);
-auth_result = AUTHZ_GENERAL_ERROR;
-return auth_result;
-}
-apr_table_setn(r-notes, AUTHZ_PROVIDER_NAME_NOTE,
- AUTHZ_DEFAULT_PROVIDER);
-}
-else {
-provider = current_provider-provider;
-apr_table_setn(r-notes, AUTHZ_PROVIDER_NAME_NOTE,
- current_provider-provider_name);
-}
-
/* check to make sure that the request method requires
* authorization before calling the provider
*/
Index: modules/aaa/mod_auth.h
===
--- modules/aaa/mod_auth.h (revision 384494)
+++ modules/aaa/mod_auth.h (working copy)
@@ -38,7 +38,6 @@
#define AUTHN_PROVIDER_GROUP authn
#define AUTHZ_PROVIDER_GROUP authz
#define AUTHN_DEFAULT_PROVIDER file
-#define AUTHZ_DEFAULT_PROVIDER default
#define AUTHZ_GROUP_NOTE authz_group_note
#define AUTHN_PROVIDER_NAME_NOTE authn_provider_name
]]]
Max
+1 During the develop, mod_authz_default flip-flopped between being a
provider vs. hook. It turned out that ultimately authz_default need to
remain a hook so that it could be guaranteed to run last. So the
provider 'default' doesn't actually exist. Also given that with the
checks that are in place before check_provider_list() is called prevent
current_provider from being a NULL value, removing the code that
attempts to load a default authz provider seems reasonable. Also the
concept of a default provider should happen fairly automatically anyway
since the access control directives 'Allow/Deny' have been folded in as
providers. Setting 'Require All Granted' or 'Require All Denied' for a
directory carries through to sub directories as a default provider.
Given that our standard httpd.conf specifies 'Require all denied' for
root, the 'all denied' becomes the default provider.
Brad
Re: [PATCH] Re: mod_authz_core:check_provider_list bug?
{ On 3/9/2006 at 10:15:33 am, in message
[EMAIL PROTECTED], Max
Bowsher
[EMAIL PROTECTED] wrote:
(((
since the access control directives 'Allow/Deny' have been folded in
as
providers.
)))
^^^ This bit isn't true.
What do you mean? The actual directives are only supported in trunk
through the compatibility module mod_access_compat. This module as well
as the directives will only live on until Apache 3.0. The functionality
has been folded into mod_authz_host and will live on as authz providers,
hence access control has been folded into the current authz architecture
as providers.
Brad
Re: [PATCH] Re: mod_authz_core:check_provider_list bug?
On 3/9/2006 at 10:37:53 am, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: On 3/9/06, Brad Nicholes [EMAIL PROTECTED] wrote: What do you mean? The actual directives are only supported in trunk through the compatibility module mod_access_compat. This module as well BTW, can we consider dropping the warning about the deprecated authz directives in mod_access_compat to info instead of warn? With warn, it appears in the default error log whenever a new child spins up. Ouch. -- justin I don't have any objection to dropping the loglevel. It kind of depends on how annoying we want to be in order to get people to change their configuration to be compatible going forward. If there are no other objections, I'll make the change and get the patch committed. Brad
Re: Bugzilla components for new/renamed auth modules
{ On 3/3/2006 at 8:31:22 am, in message [EMAIL PROTECTED],
Max Bowsher
[EMAIL PROTECTED] wrote:
LDAP is in a weird situation: there are 3 components: mod_auth_ldap,
mod_authn_ldap and mod_authz_ldap, despite the fact that the last two
don't exist as real modules at all.
The actual module names are mod_ldap (aka util_ldap) and
mod_authnz_ldap. The three components should be mod_ldap,
mod_authn_ldap and mod_authz_ldap. mod_auth_ldap was the name of the
auth module in Apache 2.0 when it was classified as experimental.
Brad
