httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 47039] New: FollowSymlinks / SymlinksIfOwnerMatch doesn't work with server side includes
Date Thu, 16 Apr 2009 13:54:14 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=47039

           Summary: FollowSymlinks / SymlinksIfOwnerMatch doesn't work
                    with server side includes
           Product: Apache httpd-2
           Version: 2.2.11
          Platform: All
        OS/Version: Linux
            Status: NEW
          Keywords: PatchAvailable
          Severity: normal
          Priority: P2
         Component: Core
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: mikevs@xs4all.net


Created an attachment (id=23499)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23499)
proposed patch that fixes the bug

1. BUG DESCRIPTION

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.

2. HOW TO REPRODUCE

Reproduce with:

  * server settings

    Options FollowSymlinks # usually the default

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

  * 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.

3. PROPOSED PATCH

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.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message