Before I have used both LDAP and User/Group files for regulating access in quite a deep hierarchy of sub-directories. I have had no problems in adding or removing access in any combination that I want. However, now when I use SSLRequire (and client certificates) I seem to have no way to *add* access as I go down in my hierarchy. E.g. <Directory /htdocs/sub1> SSLRequire %{SSL_CLIENT_S_DN_C} eq "US" </Directory <Directory /htdocs/sub1/sub2> SSLRequire %{SSL_CLIENT_S_DN_C} eq "CA" </Directory A user with a "CA" certificate will not be able to access sub1/sub2/ because he/she has no access in sub1/. I.e you can only *restrict* access as you go down in the hirarchy, you cannot *add* access. A similar issue was discussed in bug # 41911. I will call this a bug. Using LDAP or User/Group files this would be perfectly OK to access sub1/sub2/ but still have no access in sub1/. I have seen this problem reported in other mailing lists as well and one guy suggested to test on REQUEST_URI in addition to the SSL* environment variables. I tried this, but since the number if subdirectories I have is so big, the regular expression got too big (the httpd.conf parser could not parse it). Any feedback is welcome. Thanks.
As we discussed in 41911, you can achieve the objective by url rewriting. I still believe that if there is a restriction on subdir1 then subdir1/subdir2 can not bypass that restriction. It seems counter intuitive to me. I think that in most of the cases, rearranging the subdirectories and url rewriting will solve the issue.
(In reply to comment #1) > As we discussed in 41911, you can achieve the objective by url rewriting. > I still believe that if there is a restriction on subdir1 then subdir1/subdir2 > can not bypass that restriction. It seems counter intuitive to me. I think that > in most of the cases, rearranging the subdirectories and url rewriting will solve > the issue. Well, what's intuitive for a person is always a subjective thing. I my case I have a structure that I have used for 10 years (!) where I want to migrate just the authentication protocol to using client certs (from the use of LDAP and standard user/group authentication). It consists of thousands of subdirectories where today 462 subdirectories all need individual/unique access rights (a combination of 275 individual users). To me it is intuitive that I can use the same directory structure independent of authentication protocol. Using LDAP and/or user/group access had no limitations. To me it is also intuitive that you gain improved security by first restricting *all* access to the whole web server and then open up where you want. Using the reverse approach you need to remember to restrict access to all nodes where you don't want access. People will tell you loudly if they don't get the access they expect but they will never tell you if they have too much access. Any feedback is appreciated. Thanks.
>To me it is also intuitive that you gain improved security by first restricting >*all* access to the whole web server and then open up where you want. Directory container permissions works in reverse way that's why we observe this issue. I believe apache way of securing directories is inherited from unix file system security. The philosophy is that that to enter a particular level, you need to have permission to all levels above it.
(In reply to comment #3) > >To me it is also intuitive that you gain improved security by first restricting > >*all* access to the whole web server and then open up where you want. > Directory container permissions works in reverse way that's why we observe this > issue. > I believe apache way of securing directories is inherited from unix file system > security. The philosophy is that that to enter a particular level, you need to > have permission to all levels above it. Well, I understand what you say about the UNIX file system but you cannot say that this is 'The Apache way' since among the 3 different authentication schema that I have used, 'mod_ssl' is the only one enforcing this. As I have stated before in this thread, neither 'mod_auth' nor 'mod_ldap' enforces this. On the contrary, a lot of the documentation I have seen describes *my* scenario.
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.