www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: other/3139: [PATCH] disallow access to hard linked files
Date Mon, 05 Oct 1998 17:20:00 GMT
The following reply was made to PR other/3139; it has been noted by GNATS.

From: Marc Slemko <marcs@znep.com>
To: Paul Bennett <p.a.bennett@btinternet.com>
Cc: apbugs@hyperreal.org
Subject: Re: other/3139: [PATCH] disallow access to hard linked files
Date: Mon, 5 Oct 1998 10:08:35 -0700 (PDT)

 On 5 Oct 1998, Paul Bennett wrote:
 
 > >Description:
 > Thanks to Apache's "SymLinkIfOwnerMatch" Option, it's possible to protect 
 > against content authors trying to get around UNIX's security by creating a
 > soft link to a protected file and using Apache to display the file.
 > 
 > There is currently no fix for hard links.
 > 
 > I have come across this on a server running as root (!), where a quick
 >   % ln /etc/shadow ~/public_html/shadow
 > Allowed all to read the contents of /etc/shadow through http://server/~me/shadow
 
 Well, that is really their problem.  Running it as root there are many
 ways to do similar things.
 
 > >Fix:
 > Since a hard link cannot be distinguished from the original file, there's no way
 > of implementing a HardLinkIfOwnerMatch option.  However, we can tell when a file
 > has more than one link through stat's st_nlink member.  If the file isn't a
 > directory and st_nlink > 1, a hard link has been created to the original file.
 > 
 > (If it's a directory, st_nlink will always be > 1, and unless we look at the
 > directory's contents, we have no way of knowing whether an extra hard link has
 > been created, but that doesn't matter 'cause only root can hard link to
 > directories, anyway.)
 > 
 > The patch below modifies the behaviour of the 'AllowSymLinks' option.  With said
 > option not set, Apache refuses to serve files with a link count > 1.  I wanted
 > to introduce a new option to do this, but as you know we've run out of bits in
 > the option structure.
 
 The problem with this is it introduces a new denial of service attack: all
 someone has to do is link to some other person's content, and suddenly
 access is denied.  
 
 I do agree that there are situations where people linking to content can
 be problematic, but I'm afraid that this solution can be even more
 problematic...
 

Mime
View raw message