From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HqOc4-0001PS-0b for qemu-devel@nongnu.org; Tue, 22 May 2007 03:16:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HqOc2-0001P8-JM for qemu-devel@nongnu.org; Tue, 22 May 2007 03:16:55 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HqOc2-0001P5-ED for qemu-devel@nongnu.org; Tue, 22 May 2007 03:16:54 -0400 Received: from wr-out-0506.google.com ([64.233.184.225]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HqOc2-0004CM-6O for qemu-devel@nongnu.org; Tue, 22 May 2007 03:16:54 -0400 Received: by wr-out-0506.google.com with SMTP id i20so3141961wra for ; Tue, 22 May 2007 00:16:53 -0700 (PDT) Message-ID: <53fbb7580705220016y5b30a746oa97343fa8c137377@mail.gmail.com> Date: Tue, 22 May 2007 10:16:52 +0300 From: "Lauri Leukkunen" Sender: lauri.leukkunen@gmail.com Subject: Re: [Qemu-devel] [PATCH][UPDATED] Fix path mangling in linux-user/path.c In-Reply-To: <20070522060824.GA5584@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <53fbb7580705211623n3c0c3bf2x9e68842fc25a43be@mail.gmail.com> <20070522060824.GA5584@localhost.localdomain> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 5/22/07, Kirill A. Shutemov wrote: > On [Tue, 22.05.2007 02:22], Lauri Leukkunen wrote: > > Attached patch fixes the linux-user path mangling code for use with > > real target root filesystems that have nasty symlinks and lots of > > files. The old code is terribly slow and can easily end up going > > through the entire host system /usr hierarchy in a recursive loop. > > > > Compared to the previous version of this patch, fixes an issue with > > attempting to free() a pointer returned by GNU basename(). > > My patch to solve same problems attached The added complexity of my version comes from preventing leaking out of the "chroot" through symlinks or "../.." elements. If we have $HOME/buildroot/usr/lib/libfoo.so.1 -> /usr/lib/libfoo.so.1.2 -> /usr/lib/libfoo.so.1.2.3 and if the buildroot and host system have different versions of the library, realpath can't be used. It gets a little messy, I agree. I had to do similar logic in scratchbox2 to maintain the fake chroot. regards, Lauri