Re: [PATCH] ext4: forbid encrypting root directory

[Eric Biggers <ebiggers3@gmail.com>]

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