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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 14 Mar 2019 08:34:33 +0100 From: Miklos Szeredi <miklos@...redi.hu> To: Richard Weinberger <richard@....at> Cc: Eric Biggers <ebiggers@...nel.org>, Amir Goldstein <amir73il@...il.com>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, linux-fscrypt@...r.kernel.org, overlayfs <linux-unionfs@...r.kernel.org>, linux-kernel <linux-kernel@...r.kernel.org>, Paul Lawrence <paullawrence@...gle.com> Subject: Re: overlayfs vs. fscrypt On Wed, Mar 13, 2019 at 11:42 PM Richard Weinberger <richard@....at> wrote: > > Am Mittwoch, 13. März 2019, 23:26:11 CET schrieb Eric Biggers: > > What specifically is wrong with supporting the ciphertext "view" of encrypted > > directories, and why do you want to opt UBIFS out of it specifically but not > > ext4 and f2fs? (The fscrypt_operations are per-filesystem type, not > > per-filesystem instance, so I assume that's what you had in mind.) Note that we > > can't unconditionally remove it because people need it to delete files without > > the key. We could add a mount option to disable it, but why exactly? > > You are right, fscrypt_operations is the wrong structure. > My plan was having it per filesystem instance. So a mount-option seems like > a good option. Of course for all filesystems that support fscrypt, not just UBIFS. Yes, please. Changing filesystem contents based on a mount option is orders of magnitude more sane than doing so on key insertion/removal. Thanks, Miklos
Powered by blists - more mailing lists