Message-ID: <3574381B.4DAE7925@chpc.utah.edu>
Date: Tue, 02 Jun 1998 11:36:27 -0600
From: Lou Langholtz <ldl@chpc.utah.edu>
Organization: Center for High Performance Computing
MIME-Version: 1.0
To: new-httpd@apache.org
Subject: Re: configfile_t.param
References: <Pine.LNX.3.96dg4.980601180429.2714D-100000@twinlark.arctic.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

Dean Gaudet wrote:

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

. . .

Dean, I've though about hard links and am afraid to tell you that I can't see how
they could work around all the checks I've mentioned so far. I'd imagine you've
had to consider this a lot more times than I though. But if I'm really missing
something on hard links, please explain how they could comprimise the checks.

Thanks.