[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170623042720.r6bhmp7ru5vfcrfx@thunk.org>
Date: Fri, 23 Jun 2017 00:27:20 -0400
From: Theodore Ts'o <tytso@....edu>
To: Andreas Dilger <adilger@...ger.ca>
Cc: Eric Biggers <ebiggers3@...il.com>,
linux-ext4 <linux-ext4@...r.kernel.org>,
linux-fscrypt@...r.kernel.org,
Andreas Dilger <adilger.kernel@...ger.ca>,
Jaegeuk Kim <jaegeuk@...nel.org>,
Eric Biggers <ebiggers@...gle.com>
Subject: Re: [PATCH v2] ext4: forbid encrypting root directory
On Mon, Jun 19, 2017 at 03:18:24PM -0600, Andreas Dilger wrote:
> On Jun 16, 2017, at 12:34 PM, Eric Biggers <ebiggers3@...il.com> wrote:
> >
> > From: Eric Biggers <ebiggers@...gle.com>
> >
> > Currently it's possible to encrypt all files and directories on an ext4
> > filesystem by deleting everything, including lost+found, then setting an
> > encryption policy on the root directory. However, this is incompatible
> > with e2fsck because e2fsck expects to find, create, and/or write to
> > lost+found and does not have access to any encryption keys. Especially
> > problematic is that if e2fsck can't find lost+found, it will create it
> > without regard for whether the root directory is encrypted. This is
> > wrong for obvious reasons, and it causes a later run of e2fsck to
> > consider the lost+found directory entry to be corrupted.
> >
> > Encrypting the root directory may also be of limited use because it is
> > the "all-or-nothing" use case, for which dm-crypt can be used instead.
> > (By design, encryption policies are inherited and cannot be overridden;
> > so the root directory having an encryption policy implies that all files
> > and directories on the filesystem have that same encryption policy.)
> >
> > In any case, encrypting the root directory is broken currently and must
> > not be allowed; so start returning an error if userspace requests it.
> > For now only do this in ext4, because f2fs and ubifs do not appear to
> > have the lost+found requirement. We could move it into
> > fscrypt_ioctl_set_policy() later if desired, though.
> >
> > Signed-off-by: Eric Biggers <ebiggers@...gle.com>
>
> Reviewed-by: Andreas Dilger <adilger@...ger.ca>
Thanks, applied.
- Ted
Powered by blists - more mailing lists