From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751291AbaCUXIJ (ORCPT ); Fri, 21 Mar 2014 19:08:09 -0400 Received: from h1446028.stratoserver.net ([85.214.92.142]:58609 "EHLO mail.ahsoftware.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750868AbaCUXHm (ORCPT ); Fri, 21 Mar 2014 19:07:42 -0400 Message-ID: <532CC625.7020509@ahsoftware.de> Date: Sat, 22 Mar 2014 00:07:17 +0100 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Andrew Morton CC: linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] initramfs: print error and shell out for unsupported content References: <1395352845-7435-1-git-send-email-holler@ahsoftware.de> <20140321140305.a3679620aa25132a3b75a404@linux-foundation.org> <532CC215.1000107@ahsoftware.de> <20140321155517.51af1b28fe32656fb7506f97@linux-foundation.org> In-Reply-To: <20140321155517.51af1b28fe32656fb7506f97@linux-foundation.org> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 21.03.2014 23:55, schrieb Andrew Morton: > On Fri, 21 Mar 2014 23:49:57 +0100 Alexander Holler wrote: > >> Am 21.03.2014 22:03, schrieb Andrew Morton: >>> On Thu, 20 Mar 2014 23:00:45 +0100 Alexander Holler wrote: >>> >>>> The initramfs generation is broken for file and directory names which contain >>>> colons or spaces. Print an error and don't try to continue. >> >>> It would be better to fix the it-doesnt-work-with-all-filenames bug. >>> Any details on that? >> >> IMHO not worth the time. The whole process which is curently used is >> extremly fragile. >> >> E.g it's almost guaranteed to fail trying to include arbitrary filenames >> as dependencies in a Makefile. Besides the one problem I've discoverd >> with colons, there could be much more things happen, e.g. with filenames >> which do include other special Makefile characters you all would have to >> escape correctly. >> >> And the problem with spaces isn't as easy to fix as it first does look >> like. I think it might be easier to write the whole stuff new instead of >> trying to escape the spaces in various ways needed to end up correctly >> in the cpio (it first goes through shell code and is then feeded as some >> list to a C program). >> >> And I think that just isn't worth the time. Using find | cpio works just >> fine to generate a cpio archive and usually an initramfs just contains >> some megabytes. So it isn't a problem at all to rebuild the complete >> cpio archive with every call of make, it doesn't need much more than >> about a second or similiar on almost any machine. >> >> And for the records, I indeed had a deeper look, trying to fix it. But, >> as said, quickly realized that it will need too much effort and doesn't >> make sense, if it will be doable correctly at all. >> > > huh, OK. > > Should we check for \t and \n as well? Hmm, maybe. But usually there aren't filenames wich do contain those characters, and if you want to break (or exploit) the kernel build process, there are easier ways. But colons and spaces are more widely used, e.g. the colons in my initramfs were generated by bluez (look at /var/lib/bluetooth). I think the current process is good enough for most stuff one wants to put into an initramfs, and it has the great feature of the uid/guid translation. So just a quick check to avoid the most basic problems should be ok. And I don't really see a need to check for \t and \n too, because nobody sane uses them in filenames. But ok, that just would be a few chars more in the regex for find. ;) I leave that up to you. Regards, Alexander Holler