httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: configfile_t.param
Date Tue, 02 Jun 1998 01:09:21 GMT


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


Mime
View raw message