| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 26 Mar 2014 22:55:03 +0100 From: Alexander Holler <holler@...oftware.de> To: Levente Kurusa <levex@...ux.com> CC: Andrew Morton <akpm@...ux-foundation.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v2] initramfs: print error and shell out for unsupported content Am 26.03.2014 22:38, schrieb Levente Kurusa: > Hi, > > 2014-03-26 22:16 GMT+01:00 Alexander Holler <holler@...oftware.de>: >> Am 22.03.2014 00:07, schrieb Alexander Holler: >>> >>> Am 21.03.2014 23:55, schrieb Andrew Morton: >>> >>>> On Fri, 21 Mar 2014 23:49:57 +0100 Alexander Holler >>>> <holler@...oftware.de> wrote: >>>> >>>>> Am 21.03.2014 22:03, schrieb Andrew Morton: >>>>>> >>>>>> On Thu, 20 Mar 2014 23:00:45 +0100 Alexander Holler >>>>>> <holler@...oftware.de> 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. >> >> >> To be a bit more verbose, (gnu)make doesn't support quoted filenames. That >> means one has to escape all kind of characters which might have a special >> meaning for make. Not really doable. Furthermore escaped characters are not >> very well supported by make and are usable only by a few rules. >> >> >>>>> 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). >> >> >> To be a bit more verbose here, the shell script >> (scripts/gen_initramfs_list.sh) identifes filenames based on the position in >> a string which is delimited by the usual (shell) whitespace. E.g. $1 = >> filename, $2 = mode, ... >> And this stuff is then feeded to usr/gen_init_cpio.c,which uses a similiar >> approach like >> >> sscanf(line, "%" str(PATH_MAX) "s %" str(PATH_MAX) "s %o %d %d", name, >> target, ... >> >> which obviously fails for filenames with whitspace too. >> >> What I think might be reasonable is: >> >> - get rid of the dependency list in form of a include into the Makefile and >> just generate the cpio-archive every time make is called. Common initramfs >> sizes are about a few megabytes and with today machines such a cpio-archive >> is build in about a second, >> > > I don't understand what kind of include would you want. > >> - get rid of gen_initramfs_list.sh and rewrite gen_init_cpio.c such that it >> reads the filenames, modes and similiar itself (e.g. by using stat(2)). > > This is walkable but probably not worth the effort. Besides, why would > anyone want to put spaces, colons and arbitrary characters to filenames > in the initramfs? > >> >> >> But I don't have any motivation to do so. Sorry. >> >> Maybe Levente Kurusa is interested in doing so, he seems to have an interest >> in the topic as he was quiet fast to send an answer to my patch. > > All I wonder now is why are you being so arrogant. You are not a 'remote > keyboard' as you had called yourself, since when you send a patch > you not only have to send it but communicate WHY maintainers > should take that patch, and if somebody has a comment The patch clearly explained what's broken. > spotting an obvious mistake you shouldn't become angry. > It was only a simple typo and a suggestion. Nobody told you > to blindly accept my suggestion. Everybody can have opinions. > It's open-source, the community suggests you new changes, > it's normal, get used to it. Writing up this nonsense sentence > (I feel the irony) probably took more time than actually resending > the patch did. So please accept my opinion that I'm not interested in fixing silly typos until I had at least some feedback with reasonable content. E.g. a Tested-By would have been nice. And please forgive me that I'm unable to differentiate between feedback from "someone" or by a maintainer. Maybe I was fooled by that linux.com in your email, I had forgotten that this is a public available mail address. So, Thanks for supporting the Linux Foundation. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists