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: Mon, 17 Nov 2014 11:32:07 +0100 From: Miklos Szeredi <miklos@...redi.hu> To: Jordi Pujol Palomer <jordipujolp@...il.com> Cc: linux-unionfs@...r.kernel.org, Linux-Fsdevel <linux-fsdevel@...r.kernel.org>, Kernel Mailing List <linux-kernel@...r.kernel.org>, David Howells <dhowells@...hat.com>, Al Viro <viro@...iv.linux.org.uk>, "A. Wan" <jm@...wan.com>, Patrick Frisch <patrick@...schux.de>, Aaron Campbell <aaron@...or.net> Subject: Re: [RFC PATCH] overlayfs: support more than one read-only layer On Fri, Nov 14, 2014 at 9:55 AM, Jordi Pujol Palomer <jordipujolp@...il.com> wrote: > EL Mon, 10 Nov 2014 10:09:54 +0100 > Miklos Szeredi <miklos@...redi.hu> escrigué: > >> Maybe it wasn't clear, but the number of lower layers isn't limited by >> FILESYSTEM_MAX_STACK_DEPTH, > sorry, you have been clear, it's me that have not explained the purpose > of that patch. This idea is also valid for the main overlayfs > development. > Consider that we have an encrypted partition and a live OS that > uses overlayfs and works over it, when the OS is started already > reaches the maximum stacking depth (2). Also, hardcoding parameters > into the code may be annoying because a change implies creating and > mantaining patches, otherwise when the parameter is configurable we can > change it in a config value. Before allowing a change to FILESYSTEM_MAX_STACK_DEPTH we'd need to analyze the kernel stack usage of anything taking part in the filesystem stack. Not something that can be expected of users before they set a kernel config variable. 'Course we can change overlayfs and/or ecryptfs to use a new context for operations done on underlying layers. Not sure how much work that would be... > Also, I include a patch to explain better my first statement, > would say lowerdirs has extended the functionality of lowerdir, > therefore we can discard the lowerdir case that only works with one > lower layer and rename lowerdirs to lowerdir. It's more simple and all > the functionality is preserved. Yeah. But we also need some escaping in 'lowerdir=' argument to allow filenames with comma and colon. Current patch doesn't yet have that, but will work on it. Thanks, Miklos -- 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