archive mirror
 help / color / mirror / Atom feed
From: Omar Sandoval <>
To: "Theodore Y. Ts'o" <>
Cc: Eric Biggers <>,
	Linus Torvalds <>,
	Jaegeuk Kim <>,
	linux-fsdevel <>,
	linux-btrfs <>,
	Al Viro <>,
	Christoph Hellwig <>,
	Dave Chinner <>, Jann Horn <>,
	Amir Goldstein <>,
	Aleksa Sarai <>,
	Linux API <>,
	Kernel Team <>
Subject: Re: [PATCH RERESEND v9 0/9] fs: interface for directly reading/writing compressed data
Date: Tue, 18 May 2021 01:38:08 -0700	[thread overview]
Message-ID: <YKN88AbnmW73uRPw@relinquished.localdomain> (raw)
In-Reply-To: <>

On Mon, May 17, 2021 at 10:53:16PM -0400, Theodore Y. Ts'o wrote:
> On Mon, May 17, 2021 at 04:25:15PM -0700, Omar Sandoval wrote:
> > > Well, assuming we're talking about regular files only (so file contents
> > > encryption, not filenames encryption),
> > 
> > Yes, I was thinking of regular files. File operations using encrypted
> > names sounds... interesting, but I think out of scope for this.
> So the question I have is why would you want to get the raw encrypted
> data?  One possible reason (and this is what Michael Halwcrow and I
> had tried designing years ago) was so you could backup a device that
> had multiple users' files without having all of the users' keys ---
> and then be able to restore them.  So for example, suppose you had a
> tablet that is shared by multiple family members, and you want to be
> backup all of the data on the shared device so that it could be
> restored in case one of the kids drop the tablet in the swimming pool....
> But in order to do that, you need to be able to restore the encrypted
> files in the encrypted directories.  In practice, encrypted files
> generally exist in encrypted directories.  That's because the typical
> way fscrypt gets used is we set a policy on an empty directory, and
> then all of the newly files created files have encrypted file names,
> inherit the directory's encryption policy, and then have encrypted
> file contents.
> So do you have the encryption key, or not?  If you do have the
> encryption key, then you can ignore the issue of the file name when
> you open the file, but what's the reason why you would want to extract
> out the raw encrypted data plus the raw encryption metadata?  You're
> not going to be able to restore the encrypted file, in the encrypted
> directory name.  Perhaps it's because you want to keep the data
> encrypted while you're tranferring it --- but the filename needs to be
> encrypted as well, and given modern CPU's, with or without
> inline-crypto engines, the cost of decrypting the file data and then
> re-encrypting it in the backup key isn't really that large.
> If you don't have the encryption key, then you need to be able to open
> the file using using the encrypted name (which fscrypt does support)
> and then extract out the encrypted file name using another bundle of
> encryption metadata.  So that's a bit more complicated, but it's
> doable.
> The *really* hard part is *restoring* an encrypted directory
> hierarchy.  Michael and I did create a straw design proposal (which is
> too small to fit in the margins of this e-mail :-), but suffice it to
> say that the standard Posix system calls are not sufficient to be able
> to create encrypted files and encrypted directories, and it would have
> been messy as all hell.  Which is why we breathed a sign of relief
> when the original product requirement of being able to do
> backup/restore of shared devices went away.   :-)
> The thing is, though, just being able to extract out regular files in
> their raw encrypted on-disk form, along with their filename metadata,
> seems to be a bit of a party trick without a compelling use case that
> I can see.  But perhaps you have something in mind?

Thanks for the detailed response, Ted. I personally don't have a use
case for reading and writing encrypted data. I only care about skipping
compression/decompression, but early on it was pointed out that this API
could potentially also be used for encrypted data. The question at this
point is: if someone else comes along and solves the problems with
restoring encrypted filenames, is this interface enough for them to
restore the encrypted file data? It seems like the answer is yes, with a
couple of additions to fscrypt. I should've been clearer that I don't
have concrete plans to do this, I just wanted to leave the door open for
it so that we don't need a second, very similar interface.


  reply	other threads:[~2021-05-18  8:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17 18:35 [PATCH RERESEND v9 0/9] fs: interface for directly reading/writing compressed data Omar Sandoval
2021-05-17 18:35 ` [PATCH RERESEND v9 1/9] iov_iter: add copy_struct_from_iter() Omar Sandoval
2021-05-17 18:35 ` [PATCH RERESEND v9 2/9] fs: add O_ALLOW_ENCODED open flag Omar Sandoval
2021-05-17 18:35 ` [PATCH RERESEND v9 3/9] fs: add RWF_ENCODED for reading/writing compressed data Omar Sandoval
2021-05-17 18:35 ` [PATCH RERESEND v9 4/9] btrfs: don't advance offset for compressed bios in btrfs_csum_one_bio() Omar Sandoval
2021-05-17 18:35 ` [PATCH RERESEND v9 5/9] btrfs: add ram_bytes and offset to btrfs_ordered_extent Omar Sandoval
2021-05-17 18:35 ` [PATCH RERESEND v9 6/9] btrfs: support different disk extent size for delalloc Omar Sandoval
2021-05-17 18:35 ` [PATCH RERESEND v9 7/9] btrfs: optionally extend i_size in cow_file_range_inline() Omar Sandoval
2021-05-17 18:35 ` [PATCH RERESEND v9 8/9] btrfs: implement RWF_ENCODED reads Omar Sandoval
2021-05-17 18:35 ` [PATCH RERESEND v9 9/9] btrfs: implement RWF_ENCODED writes Omar Sandoval
2021-05-17 21:32 ` [PATCH RERESEND v9 0/9] fs: interface for directly reading/writing compressed data Linus Torvalds
2021-05-17 22:27   ` Omar Sandoval
2021-05-17 22:48     ` Eric Biggers
2021-05-17 23:25       ` Omar Sandoval
2021-05-18  0:07         ` Eric Biggers
2021-05-18  2:53         ` Theodore Y. Ts'o
2021-05-18  8:38           ` Omar Sandoval [this message]
2021-05-18 16:21             ` Theodore Y. Ts'o
2021-06-07 19:27   ` Omar Sandoval

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YKN88AbnmW73uRPw@relinquished.localdomain \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).