Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 46344 invoked by uid 500); 9 Nov 2001 20:29:37 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 46333 invoked from network); 9 Nov 2001 20:29:37 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Ryan Bloom Reply-To: rbb@covalent.net Organization: Covalent Technologies To: dev@httpd.apache.org, Michael Douglass Subject: Re: [2.0] lstat's in spite of AllowOverride None Date: Fri, 9 Nov 2001 12:28:21 -0800 X-Mailer: KMail [version 1.3] References: <20011107101143.B70423@deejai2.mch.fsc.net> <20011109141142.A96243@staff.texas.net> In-Reply-To: <20011109141142.A96243@staff.texas.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011109202822.9287646DFD@koj.rkbloom.net> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Friday 09 November 2001 12:11 pm, Michael Douglass wrote: > > > As FirstBill suggests, there are other means for caching the (l)stat > > > results, at least for the request duration, which need to be deployed. > > > But dropping the path_info walk-backwards logic was step one. Any > > > optimization patches are entertianed to speed up the server, if we > > > don't lose stability. > > > > Caching the lstat() results should help, but reducing to a single stat() > > as I suggest would seem better still? > > I'd be weary of caching the lstat() information for more than the current > connection; you don't want someone to abuse that cache by creating a > symlink AFTER letting apache cache the information. > > Anyone think about using resolvepath() as an initial check? resolvepath() > is a single system call to take a path to a file and convert it to the > resultant path after following all symlinks. Thus you could have a single > call to resolvepath() and strcmp() to see if there were any symlinks in > the path--if there were then you either "deny" it if symlinks are not > allowed at all; or you proceed with the lstat() scheme otherwise. > > This would seem to circumvent alot of lstat() calls on the (hopefully) > normal case that there are no symlinks involved anywhere. :) The problem is that you can deny SymLinks at any point in the path. We could use resolvepath(), but then we would need to walk the path anyway to make sure that Symlinks are allowed all the way down. Ryan ______________________________________________________________ Ryan Bloom rbb@apache.org Covalent Technologies rbb@covalent.net --------------------------------------------------------------