Bug 53581 - FollowSymlinks doesn't work with DirectoryMatch and Alias
Summary: FollowSymlinks doesn't work with DirectoryMatch and Alias
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.2.16
Hardware: All All
: P2 blocker (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2012-07-21 22:40 UTC by Christoph Anton Mitterer
Modified: 2018-11-07 21:09 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Anton Mitterer 2012-07-21 22:40:18 UTC
Hi.

I found a strange issue...
What I have is about the following:

        Alias /icinga/images/icinga/favicon.ico /srv/www/external/virtual-hosts/lcg-lrz-monitoring.grid.lrz.de/custom/icinga/images/icinga/favicon.ico

...

        <DirectoryMatch "^(?:/usr/share/icinga-web/app/modules/\w+/pub/images|/usr/share/icinga-web/app/modules/\w+/pub/styles|/usr/share/icinga-web/lib/ext3|/usr/share/icinga-web/pub|/srv/www/external/virtual-hosts/lcg-lrz-monitoring.grid.lrz.de/custom/icinga(?!/classic))/">

#some stuff adding authorization control
        </DirectoryMatch>

        <DirectoryMatch "^/srv/www/external/virtual-hosts/lcg-lrz-monitoring.grid.lrz.de/custom/icinga(?!/classic)/">
                Options +symLinksIfOwnerMatch
        </DirectoryMatch>


In /srv/www/external/virtual-hosts/lcg-lrz-monitoring.grid.lrz.de/custom/icinga there is a symlink, pointing to the favicon.ico.



So the idea is the following:
A user accesses /icinga/images/icinga/favicon.ico which is aliased to
/srv/www/external/virtual-hosts/lcg-lrz-monitoring.grid.lrz.de/custom/icinga/images/icinga/favicon.ico
which is a symlink to some other place.

The first DirectoryMatch matches some other dirs and the dir where I'm aliasing to (without the subdir classic).... and adds some general rules (mainly authorisation).

The second DirectoryMatch matches only:
/srv/www/external/virtual-hosts/lcg-lrz-monitoring.grid.lrz.de/custom/icinga and subdirs (except classic) thereof.

I'd have expected that access is granted (due to the Options +symLinksIfOwnerMatch) but I get a forbidden and:
[Sun Jul 22 00:26:36 2012] [error] [client 1.2.3.4] Symbolic link not allowed or link target not accessible: /srv/www/external/virtual-hosts/lcg-lrz-monitoring.grid.lrz.de/custom/icinga/images/icinga/favicon.ico
in the error log.

Actually the above thing exactly works if I replace the 2nd DirectoryMatch with:
        <Directory /srv/www/external/virtual-hosts/lcg-lrz-monitoring.grid.lrz.de/custom/icinga>
                Options +symLinksIfOwnerMatch
        </Directory>
which is however not a real solution, as I don't want to match the classic subdir(s).

Changing to +followSymlinks doesn't change.

It somehow seems as if followSymlinks/symLinksIfOwnerMatch don't work in DirectoryMatch blocks.


Any ideas?


Chris.
Comment 1 Eric Covener 2012-07-22 01:10:58 UTC
Reassgning to docs.  It's a limitation of the symlink related related options because they're used while resolving the Directory sections.
Comment 2 Christoph Anton Mitterer 2012-07-22 01:59:40 UTC
Hey Eric.

So you mean it's "intended" not to work?

Can't it be made to work? I mean this is quite some limitation, IMHO.


Cheers,
Chris.
Comment 3 Eric Covener 2012-07-22 13:03:12 UTC
(In reply to comment #2)
> Hey Eric.
> 
> So you mean it's "intended" not to work?
> 
> Can't it be made to work? I mean this is quite some limitation, IMHO.

Hard to tell the intent, but that's how it works. 

If you want to discuss it, use the mailing list. If you want to open a separate bug/RFE, go right ahead.  My primary concern is getting the presumably long-standing behavior documented.
Comment 4 Christoph Anton Mitterer 2012-07-22 13:41:24 UTC
Uhm well this one here was intended to be the RFE,... even though this doesn't seems like an enhancement but rather like a clear bug to me.
And just documenting it doesn't solve a bug, even though it's probably a good idea to do so, if it won't be fixed quickly.


But why opening a new ticket for this? Nothing stops from using this one and you still can add a note about this bug to the documentation.
Assigning it to the appropriate maintainer or component and he can fix it once he likes.


I'm not sure what discussion on the lists should help.... it's quite clear that this is a bug, and that wouldn't be much more like a momentum search whether there is anyone who wants to work on it right now.


Cheers,
Chris.
Comment 5 Eric Covener 2012-07-22 14:25:39 UTC
Changing to RFE. It's already documented in sections.html
Comment 6 Eric Covener 2012-07-22 14:49:06 UTC
(In reply to comment #5)
> Changing to RFE. It's already documented in sections.html

copied to the doc for the actual Options affected
Comment 7 William A. Rowe Jr. 2018-11-07 21:09:48 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.