From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jx0i4-0002oQ-Qa for qemu-devel@nongnu.org; Fri, 16 May 2008 10:15:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jx0i2-0002o0-R5 for qemu-devel@nongnu.org; Fri, 16 May 2008 10:14:59 -0400 Received: from [199.232.76.173] (port=57528 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jx0i2-0002nv-Hq for qemu-devel@nongnu.org; Fri, 16 May 2008 10:14:58 -0400 Received: from bsdimp.com ([199.45.160.85]:60288 helo=harmony.bsdimp.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Jx0i2-0001gj-3i for qemu-devel@nongnu.org; Fri, 16 May 2008 10:14:58 -0400 Date: Fri, 16 May 2008 08:09:40 -0600 (MDT) Message-Id: <20080516.080940.74651723.imp@bsdimp.com> Subject: Re: [Qemu-devel] Use of PATH_MAX From: Warner Losh In-Reply-To: <482D9387.7070807@codemonkey.ws> References: <18477.36259.30442.280531@mariner.uk.xensource.com> <482D9387.7070807@codemonkey.ws> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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, anthony@codemonkey.ws From: Anthony Liguori Subject: Re: [Qemu-devel] Use of PATH_MAX Date: Fri, 16 May 2008 09:00:39 -0500 > Ian Jackson wrote: > > There are a couple of places where we use PATH_MAX. I don't think > > this is right. PATH_MAX is a #define specified by POSIX, SuSv3 etc. > > But it isn't guaranteed to be defined or necessarily very useful. > > > > In particular, it may be defined to a very large value (larger than a > > practical static buffer). Or on systems where the maximum pathname > > length varies (for example, it depends on the underlying filesystem) > > it may be not defined at all and applications which really need to > > know are supposed to use pathconf. > > > > I think it would be better to invent a new name for the maximum path > > length supported by qemu's statically-sized buffers. This would > > replace both the uses of PATH_MAX (in block.c, linux-user/path.c, and > > block-vvfat.c) but also direct use of (eg) 1024 in many places. > > > > It would be far better to get rid of instances of PATH_MAX and replace > them with dynamically allocated buffers. The use of static sized > buffers for filenames is just asking for subtle bugs (and possibly even > security problems. As is the use of dynamic buffers. If you don't always test system call return value, you can get odd new failures. If you don't provide a sane upper bound, then you get DoS attacks... Warner