Date: Mon, 1 Jun 1998 18:09:21 -0700 (PDT)
From: Dean Gaudet <dgaudet@arctic.org>
To: new-httpd@apache.org
Subject: Re: configfile_t.param
In-Reply-To: <199806020026.SAA09799@eden.chpc.utah.edu>
Message-ID: <Pine.LNX.3.96dg4.980601180429.2714D-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


On Mon, 1 Jun 1998, Lou Langholtz wrote:

> > BTW, your technique also fails on unixes which allow folks to "chown away"
> > files.  For example, on IRIX you can "chown someoneelse .htaccess", and it
> > will let you give away the file.
> > 
> > Also on any unix I can:
> > 
> >     mkdir public_html/teehee
> >     cd public_html/teehee
> >     ln -s ~victim/public_html/.htaccess
> > 
> > and your fstat() will return the userid of the victim.
> > 
> > Dean
> 
> Thanks. Good points.
> 
> Fortunately I can also use the behavior of the set
> user id bit to get around chown'ing away the htacces file, and can lstat the
> parms->config_file->name to disallow htaccess files that are symlinks.
> Additionally I can check that the device and inode are the same between the
> result from the fstat() and the lstat(). Have I missed anything?

hard links.

> Now how about we go back to discussing a standard way to get the htaccess
> file descriptor :-) Also the, filename so long as I've brought it up. I'd
> really like to avoid the case where the directives are read out of one
> file and then security is tricked by lstat()'ing another file without
> resorting to reparsing the htaccess file in my module. I can do that
> I believe by checking that the inode and device numbers match between the
> fstat() and the lstat() but only if I can get the descriptor for the fstat()

As I've said already:  there may not be a file descriptor.  There may not
even be a filename, the name parameter is a descriptive text intended for
human consumption (in error messages).  The method you're using won't work
at all.  In fact it won't even compile in 1.3.0 because I made poolfile_t
a private type in util.c... it shouldn't have been public, it is a private
interface. 

I suspect that there's an entirely easier solution that isn't prone to
security problems.  If this is crud in ~user URLs then just use the
embedded user in the URL.  Otherwise it's probably crud under a
/blah/blah/docroot/user hierarchy (where user may be a domain name) and
you can compare against the uid of that file.  Without knowing a lot more
about your application I can't say. 

Dean