general/1402: Relative Symlinks are handled improperly

[Stig <st...@hackvan.com>]

>Number:         1402
>Category:       general
>Synopsis:       Relative Symlinks are handled improperly
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Wed Nov 12 04:50:00 PST 1997
>Last-Modified:
>Originator:     stig@hackvan.com
>Organization:
apache
>Release:        1.2.4
>Environment:
Linux JATO.hackvan.com 2.0.30 #21 Tue Sep 30 23:59:58 PDT 1997 i586 unknown
>Description:
The handling of symlinks is hosed.  There is confusion in the server between 
URL paths and filesystem path names.  The server moronically handles relative 
path symlinks manually and applies the path manipulation to the URL and not the
real pathname of the file!!!  The relative URL path is then accessed in the 
filesystem (failing of course, because this doesn't account for Alias directives).

URL:   http://localhost/pub/foo
			^^^^ Alias directive
path    /u/ftp/pub/foo     this is a link to ../bar
fuckup  /u/web/hackvan.com/pub/bar


PS:  I concur with bug 922.  Symlinks owned by root should always be respected, regardless of SymLinksIfOwnerMatch.

>How-To-Repeat:
Alias /pub    /u/ftp/pub/
cd /u/ftp/pub
touch XX
ln -s XX YY

now try to access http://host/pub/YY

you get this error:
[Wed Nov 12 04:20:04 1997] access to /u/web/hackvan.com/pub/YY failed for localhost, reason: File does not exist
>Fix:
Symlinks should be expanded in the filesystem pathname and not the URL.

To continue on a related nit...
It disturbs me that apache does not provide chmod-like behavior wrt symlinks.
The expanded name should then be checked against Directory directives to determine if
access is permitted.  
%0
>Audit-Trail:
>Unformatted: