linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Richard Weinberger <richard@nod.at>,
	linux-mtd@lists.infradead.org, linux-fscrypt@vger.kernel.org,
	jaegeuk@kernel.org, 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 19:42:30 -0400	[thread overview]
Message-ID: <20190314234230.GG6482@mit.edu> (raw)
In-Reply-To: <1552605311.2571.6.camel@HansenPartnership.com>

On Thu, Mar 14, 2019 at 04:15:11PM -0700, James Bottomley wrote:
> On Thu, 2019-03-14 at 18:15 +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.
> 
> Shouldn't they be able to read/write and create as well (all with the
> ciphertext name and contents, of course) ... otherwise how does backup
> of encrypted files by admin without the key ever work?

That's not currently supported.  Michael Halcrow and I worked out some
designs on how to do this, and I even had some prototype patches, but
it's really, really, messy, and requires a lot of complex machinations
in userspace on the save *and* restore, since there's a lot of crypto
metadata that has to be saved, and you have to handle backing up the
directory per-file keys, and restoring them when you recreate the
directory on a restore, etc.

The simpler approach would have allowed backup of encrypted files
without the key, but would require the user's key to do the restore,
and if we ever actually tried to get this feature supported, that's
the approach I'd suggest.


The fundamental reason why we never went did anything with this was
that the original use case of fscrypt was for Chrome OS, where the
original design premise was that you don't need to do backups, since
everything is in the cloud.  A video from 2010:

	https://www.youtube.com/watch?v=lm-Vnx58UYo

And with Android, backups happen automatically while you have the
encryption key.

There was talk about using fscrypt for Ubuntu desktops as an ecryptfs
replacement, and in that case, we would have use case that would have
required backups of a shared desktop where you don't have all of the
encryption keys for all of the users.  Maybe someday as a Google
Summer of Code project or maybe if some potential corporate user of
fscrypt would be willing to fund the necessary engineering work?

But again, I'll repeat this because it's so important: In the vast
majority of cases, including single-user laptops, desktops, etc., the
real right answer is dm-crypt and *not* fscrypt.  Especially since
time-sharing systems are *so* 1980's.  :-)

So I don't use fscrypt on my upstream development laptop (except for
testing purposes) because it's simply not the right tool for the job.

		      	 	    - Ted

  reply	other threads:[~2019-03-14 23:42 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
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 [this message]
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=20190314234230.GG6482@mit.edu \
    --to=tytso@mit.edu \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=amir73il@gmail.com \
    --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=richard@nod.at \
    /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).