Summary: | A reference to a broken symbolic link results in a "broken" error response page. | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | Rolf Sponsel <Rolf.Sponsel> |
Component: | Core | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | Rolf.Sponsel, rroeilck |
Priority: | P3 | ||
Version: | 2.0.49 | ||
Target Milestone: | --- | ||
Hardware: | Sun | ||
OS: | Solaris |
Description
Rolf Sponsel
2004-04-21 15:01:54 UTC
I Forgot to mention that I acctually changed one thing in the standard httpd.conf file. The 'GroupId' directive was changed from '#-1' to 'nobody'. Best Regards, Rolf Sponsel I have now studied that *other* issue mentioned at the end of my first post, and have come to the conclusion that it's very likely to be related to the problem initially posted. And therefore have decided to append it to this issue. I also have raised the severity because, under unfortunate circumstances, it could become - if not a security issue, then at least - an *integrity* issue. If you follow the same steps as described in my initial posting after having enabled the 'Customized Error Responses' feature you will notice that in the case with the broken link the standard error response is displayed instead of the customized one, one would expect. Why this might lead to an *integrity* issue? I noticed this problem in the process of "hiding" any error responses returned due to non-authorized access attempts, e.g. made by a"harvesting" web-crawler attempting to gain access to information by visiting a site via an it's IP-Address, and which will reveal information, e.g. the email address of the system's administrator, etc. And until this has been fixed it could, under unfortunate circumstances, lead to the revealing of more information than intended, by accident. As always, feel free to ask for complimentary information concerning this. Best Regards, Rolf Sponsel This same confusing error message is returned if you symlink to a path where a parent directory is not searchable by the web server user. I believe the problem is that any error returned by an apr_stat on the symlink is treated as "symlink not allowed". Instead, the real error from apr_stat should be propogated to the error log. (But this wouldn't fix the "Additionally ..." error to the browser.) SVN rev 280018 makes the error message a little more accurate but doesn't fix any of the other problems mentioned in this bug. *** Bug 36716 has been marked as a duplicate of this bug. *** This bug doesn't happen on 2.2.8 - marking fixed. I haven't tested 2.0.current. If that's not fixed, it's unlikely anyone'll want to put the effort in, so I'd suggest not reopening unless you're attaching a patch. |