From: Richard Weinberger <richard@nod.at>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-mtd@lists.infradead.org, linux-fscrypt@vger.kernel.org,
jaegeuk@kernel.org, tytso@mit.edu, linux-unionfs@vger.kernel.org,
miklos@szeredi.hu, amir73il@gmail.com,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
paullawrence@google.com
Subject: Re: [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required
Date: Thu, 14 Mar 2019 21:54:10 +0100 [thread overview]
Message-ID: <1957441.Hty6t2mpXG@blindfold> (raw)
In-Reply-To: <20190314174913.GA30026@gmail.com>
Eric,
Am Donnerstag, 14. März 2019, 18:49:14 CET schrieb Eric Biggers:
> Hi Richard,
>
> On Thu, Mar 14, 2019 at 06:15:59PM +0100, Richard Weinberger wrote:
> > Usually fscrypt allows limited access to encrypted files even
> > if no key is available.
> > Encrypted filenames are shown and based on this names users
> > can unlink and move files.
>
> Actually, fscrypt doesn't allow moving files without the key. It would only be
> possible for cross-renames, i.e. renames with the RENAME_EXCHANGE flag. So for
> consistency with regular renames, fscrypt also forbids cross-renames if the key
> for either the source or destination directory is missing.
>
> So the main use case for the ciphertext view is *deleting* files. For example,
> deleting a user's home directory after that user has been removed from the
> system. Or the system freeing up space by deleting cache files from a user who
> isn't currently logged in.
Right, I somehow thought beside of deleting you can do more.
> >
> > This is not always what people expect. The fscrypt_key_required mount
> > option disables this feature.
> > If no key is present all access is denied with the -ENOKEY error code.
>
> The problem with this mount option is that it allows users to create undeletable
> files. So I'm not really convinced yet this is a good change. And though the
> fscrypt_key_required semantics are easier to implement, we'd still have to
> support the existing semantics too, thus increasing the maintenance cost.
The undeletable-file argument is a good point. Thanks for bringing this up.
To get rid of such files root needs to mount without the new mount parameter. ;-\
> >
> > The side benefit of this is that we don't need ->d_revalidate().
> > Not having ->d_revalidate() makes an encrypted ubifs usable
> > as overlayfs upper directory.
> >
>
> It would be preferable if we could get overlayfs to work without providing a
> special mount option.
Yes, but let's see what Al finds in his review.
> > Signed-off-by: Richard Weinberger <richard@nod.at>
> > ---
> > fs/ubifs/crypto.c | 2 +-
> > fs/ubifs/dir.c | 29 ++++++++++++++++++++++++++---
> > fs/ubifs/super.c | 15 +++++++++++++++
> > fs/ubifs/ubifs.h | 1 +
> > 4 files changed, 43 insertions(+), 4 deletions(-)
> >
>
> Shouldn't readlink() honor the mount option too?
Hmmm, yes. We need to honor it in ->get_link() too.
> > + if (c->fscrypt_key_required && !dir->i_crypt_info)
> > + return -ENOKEY;
> > +
>
> How about returning -ENOKEY when trying to open the directory in the first
> place, rather than allowing getting to readdir()? That would match the behavior
> of regular files.
I'm not sure what the best approach is.
We could also do it in ->permission().
Thanks,
//richard
next prev parent reply other threads:[~2019-03-14 20:54 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-13 12:31 overlayfs vs. fscrypt Richard Weinberger
2019-03-13 12:36 ` Miklos Szeredi
2019-03-13 12:47 ` Richard Weinberger
2019-03-13 12:58 ` Miklos Szeredi
2019-03-13 13:00 ` Richard Weinberger
2019-03-13 13:24 ` Miklos Szeredi
2019-03-13 13:32 ` Richard Weinberger
2019-03-13 14:26 ` Amir Goldstein
2019-03-13 15:16 ` Theodore Ts'o
2019-03-13 15:30 ` Richard Weinberger
2019-03-13 15:36 ` James Bottomley
2019-03-13 15:51 ` Eric Biggers
2019-03-13 16:13 ` James Bottomley
2019-03-13 16:24 ` Richard Weinberger
2019-03-13 16:44 ` Theodore Ts'o
2019-03-13 17:45 ` James Bottomley
2019-03-13 18:58 ` Theodore Ts'o
2019-03-13 19:17 ` James Bottomley
2019-03-13 19:57 ` Eric Biggers
2019-03-13 20:06 ` James Bottomley
2019-03-13 20:25 ` Eric Biggers
2019-03-13 21:04 ` James Bottomley
2019-03-13 22:13 ` Eric Biggers
2019-03-13 22:29 ` James Bottomley
2019-03-13 22:58 ` Eric Biggers
2019-03-13 16:06 ` Al Viro
2019-03-13 16:44 ` Eric Biggers
2019-03-13 19:19 ` Al Viro
2019-03-13 19:43 ` Eric Biggers
2019-03-13 15:30 ` Eric Biggers
2019-03-13 20:33 ` Richard Weinberger
2019-03-13 22:26 ` Eric Biggers
2019-03-13 22:42 ` Richard Weinberger
2019-03-14 7:34 ` Miklos Szeredi
2019-03-14 17:15 ` [RFC] fscrypt_key_required mount option Richard Weinberger
2019-03-14 17:15 ` [PATCH 1/4] fscrypt: Implement FS_CFLG_OWN_D_OPS Richard Weinberger
2019-03-14 17:15 ` [PATCH 2/4] fscrypt: Export fscrypt_d_ops Richard Weinberger
2019-03-14 17:15 ` [PATCH 3/4] ubifs: Simplify fscrypt_get_encryption_info() error handling Richard Weinberger
2019-03-14 17:15 ` [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required Richard Weinberger
2019-03-14 17:49 ` Eric Biggers
2019-03-14 20:54 ` Richard Weinberger [this message]
2019-03-14 23:07 ` Theodore Ts'o
2019-03-15 7:48 ` Richard Weinberger
2019-03-15 13:51 ` Theodore Ts'o
2019-03-15 13:59 ` Richard Weinberger
2019-03-14 23:15 ` James Bottomley
2019-03-14 23:42 ` Theodore Ts'o
2019-03-14 23:55 ` James Bottomley
2019-03-13 15:01 ` overlayfs vs. fscrypt Eric Biggers
2019-03-13 16:11 ` Al Viro
2019-03-13 16:33 ` Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1957441.Hty6t2mpXG@blindfold \
--to=richard@nod.at \
--cc=amir73il@gmail.com \
--cc=ebiggers@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=paullawrence@google.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).