From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60195) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAf4h-0001Pd-8h for qemu-devel@nongnu.org; Tue, 04 Feb 2014 07:26:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WAf4X-0002MM-IN for qemu-devel@nongnu.org; Tue, 04 Feb 2014 07:25:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:8867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAf4X-0002MG-9i for qemu-devel@nongnu.org; Tue, 04 Feb 2014 07:25:49 -0500 From: Markus Armbruster References: <52EF68CA.9060604@gmail.com> <20140203103429.GB10408@redhat.com> <52EF71DC.3000309@gmail.com> <52F0C8BA.7020709@gmail.com> Date: Tue, 04 Feb 2014 13:25:40 +0100 In-Reply-To: <52F0C8BA.7020709@gmail.com> (Chen Gang's message of "Tue, 04 Feb 2014 19:02:18 +0800") Message-ID: <87vbwvoyij.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chen Gang Cc: aneesh.kumar@linux.vnet.ibm.com, aliguori@amazon.com, QEMU Developers Chen Gang writes: > On 02/03/2014 06:39 PM, Chen Gang wrote: >> On 02/03/2014 06:34 PM, Daniel P. Berrange wrote: >>> On Mon, Feb 03, 2014 at 06:00:42PM +0800, Chen Gang wrote: >>>> We can not assume "'path' + 'ctx->fs_root'" must be less than MAX_PATH, >>>> so need use snprintf() instead of sprintf(). >>>> >>>> And also recommend to use ARRAY_SIZE instead of hard code macro for an >>>> array size in snprintf(). >>> >>> In the event that there is overflow this will cause the data to be >>> truncated, potentially causing QEMU to access the wrong file on the >>> host. Both snprintf and sprintf are really bad because of their >>> use of fixed buffers. Better to change it to g_strdup_printf which >>> dynamically allocates buffers. >>> > > After check the details, I guess we can not change to g_strdup_printf or > others (e.g. v9fs_string_*). > > v9fs need use "mkdir, remove ..." which have MAX_PATH limitation. So if > the combined path is longer than MAX_PATH, before it passes to "mkdir, > remove ...", it has to be truncated just like what rpath() has done. What good could truncating possibly do? If the pathname is too long for mkdir(), truncating won't make it work, it will make it do the wrong thing. Second guessing when a pathname is too long for a system call is not a good idea. If it's too long, the system call will tell you. As Dan noted, PATH_MAX is *not* a hard limit. {PATH_MAX} Maximum number of bytes the implementation will store as a pathname in a user-supplied buffer of unspecified size, including the terminating null character. Minimum number the implementation will accept as the maximum number of bytes in a pathname. [...]