|Summary:||mod_autoindex incorrectly fails to list files|
|Product:||Apache httpd-2||Reporter:||Nick Phillips <nick.phillips>|
|Component:||mod_autoindex||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
Description Nick Phillips 2008-07-15 17:17:15 UTC
*** Long-winded description of setup *** I have a directory on a server which is to be accessible through two different URLs, one for general use (we'll call it "download") and one for management via DAV (we'll call it "upload"). The authentication and authorization is different depending on which <Location> you access it through. The upload uses LDAP for authentication, but download uses a standard htpasswd file. The download also only requires valid-user, while the DAV (upload) end also requires a group membership. Groups are defined in a standard htgroup file, not in LDAP. LDAP is only available for authentication. *** Behaviour *** When I access the download URL, the correct index is generated and files are accessible. When I access the upload URL using a DAV client, all is well. When I access the upload URL using a browser, no files are listed, and "user myusername not found:" errors are logged for each file. When I access an individual file using a browser, I am able to retrieve it. If I modify the configuration to add a <Directory> section for the underlying directory, requiring the same auth as the <Location> section for the upload URL, then I can access the upload URL using a standard browser and all files are correctly listed. If I add a myusername entry to the htpasswd file which is used for download with a different password to the LDAP one, the error in the logs changes to 'user myusername: authentication failure for "/some/path/and/file": Password Mismatch' If I add a myusername entry to the htpasswd file which is used for download with the same password as the LDAP one, the directory listing is generated correctly. *** The important bit *** Apart from the fact that my authn/authz setup is probably not optimal (!), it seems to me likely that the subrequest made by mod_autoindex (using ap_sub_req_lookup_dirent) is not able to correctly identify whether or not I have permission to access the files (which is the bug) because it has no idea which URL I used (and hence which <Location> config is relevant). The entire configuration is rather complex, besides which I'm not willing to post it publically. I would however be happy to make it available to relevant individuals, and/or to describe the config or the problem further either via IRC or email.
Comment 1 William A. Rowe Jr. 2018-11-07 21:09:06 UTC
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.