www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stig <s...@hackvan.com>
Subject general/1402: Relative Symlinks are handled improperly
Date Wed, 12 Nov 1997 12:47:35 GMT

>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
>Originator:     stig@hackvan.com
>Release:        1.2.4
Linux JATO.hackvan.com 2.0.30 #21 Tue Sep 30 23:59:58 PDT 1997 i586 unknown
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.

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

View raw message