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
| ||
|
Message-ID: <20170616175457.GA20865@gmail.com> Date: Fri, 16 Jun 2017 10:54:57 -0700 From: Eric Biggers <ebiggers3@...il.com> To: Andreas Dilger <adilger@...ger.ca> Cc: linux-ext4 <linux-ext4@...r.kernel.org>, linux-fscrypt@...r.kernel.org, Theodore Ts'o <tytso@....edu>, Jaegeuk Kim <jaegeuk@...nel.org>, Eric Biggers <ebiggers@...gle.com> Subject: Re: [PATCH] ext4: forbid encrypting root directory On Wed, Jun 14, 2017 at 08:02:05PM -0600, Andreas Dilger wrote: > >> > >> What about a special case to handle an unencrypted lost+found inode? > >> > >> There was also a patch series a while ago to explicitly add lost+found > >> into the superblock so that it could be found even if the root directory > >> was corrupted, and to allow flexibility in whether it is always shown in > >> the root directory or not (e.g. allowing ".lost+found" or similar). > > > > It could be done if the lost+found inode was not linked to from any directory > > and instead had its inode number stored in the superblock so that e2fsck could > > still find it. However, if e2fsck put files in a lost+found directory that > > doesn't exist in the filesystem directory structure, how would users retrieve > > those files? Would users be required to run a special e2fsprogs command to > > list/read/delete the files in lost+found? > > I was thinking that readdir on the root inode could insert the "lost+found" > or ".lost+found" entry dynamically, I think this is possible, but not trivial. It's not just readdir; ->lookup() would also have to special-case lookups of "lost+found", and we'd have to override the fscrypt_permitted_context() check. It would also have to be a RO_COMPAT filesystem feature, lest an unaware ext4 driver or e2fsprogs create a lost+found directory which would then be ambiguous with the "real" one. > or (a bit less pleasant) is to add a > special case that this entry is just never encrypted (could compare the > inode number to the one stored in the superblock, instead of comparing names)? I think that would be similarly difficult, as it would still require special logic in readdir and ->lookup(), and would still require a RO_COMPAT filesystem feature. Either way, not all filesystems will have the implicit "lost+found" directory feature, so we're still going to need to forbid encrypting the root directory on some filesystems anyway. Eric
Powered by blists - more mailing lists