Bug 47039 - FollowSymlinks / SymlinksIfOwnerMatch doesn't work with server side includes
Summary: FollowSymlinks / SymlinksIfOwnerMatch doesn't work with server side includes
Status: RESOLVED DUPLICATE of bug 45959
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.2.11
Hardware: All Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: PatchAvailable
Depends on:
Reported: 2009-04-16 06:54 UTC by Miquel van Smoorenburg
Modified: 2009-04-16 08:06 UTC (History)
0 users

proposed patch that fixes the bug (3.33 KB, patch)
2009-04-16 06:54 UTC, Miquel van Smoorenburg
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Miquel van Smoorenburg 2009-04-16 06:54:10 UTC
Created attachment 23499 [details]
proposed patch that fixes the bug


This bug is present in apache 2.2.3 and 2.2.9, so likely all 2.2.x versions.

The Options settings "FollowSymlinks" and "SymlinksIfOwnerMatch"
do not work for files included using SSI when the files are symlinks
and located in the same directory.


Reproduce with:

  * server settings

    Options FollowSymlinks # usually the default

    <VirtualHost testhost>
        ServerName testhost.test.tld
        <Directory /var/www/>
        Options Indexes IncludesNoExec # note no FollowSymlinks

  * index.shtml file:

    <Pre><!--#include file="foo.txt"--></Pre><P>
    <Pre><!--#include file="root_link_to_foo.txt"--><Pre><P>
    <Pre><!--#include file="user_link_to_foo.txt"--><Pre>
  * data files / links:

    -rw-r--r-- 1 root   root    25 Sep  7 11:47 foo.txt
    lrwxrwxrwx 1 root   root    10 Sep  7 12:32 root_link_to_foo.txt -> foo.txt
    lrwxrwxrwx 1 www    www      7 Sep  7 15:09 user_link_to_foo.txt -> foo.txt

    (the last link is used to check if SymlinksIfOwnerMatch works)

The index.shmtl files will now show the contents of 'foo.txt'
three times, even though it should error out on the symlinks.


The patch below fixes things in three places:

  a. in ap_sub_req_lookup_file(), ap_allow_options() is used to
     find out if OPT_SYM_LINKS is set. However this is done on
     the 'rnew' variable, which points to a just created subrequest.
     The rnew->per_dir_config is still the default, so using
     ap_sub_req_lookup_file(rnew) is wrong. We can just use
     the main request though - it's a file in the same directory.

  b. ap_directory_walk() builds a cache for requests in the same
     directory. It overwrites the r->finfo data with a new
     apr_stat() without APR_FINFO_LINK, so we forget if the file
     is a symlink. We must save the old r->finfo for re-use.
  c. If the directory cache is used, the file is not re-examined to
     see if it is a link. We need to run resolve_symlink() if the
     file actually is a symlink (using the saved data from b.) to
     see if that link is allowed here.

Note that no unnecessary extra overhead is introduced.

The patch applies cleanly to both 2.2.9 and 2.2.11.
Comment 1 Bob Ionescu 2009-04-16 08:06:13 UTC
Another patch to fix the issue was applied in r733754

*** This bug has been marked as a duplicate of bug 45959 ***