From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Omar Sandoval <osandov@osandov.com>
Cc: Eric Biggers <ebiggers@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Jaegeuk Kim <jaegeuk@kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Christoph Hellwig <hch@infradead.org>,
Dave Chinner <david@fromorbit.com>, Jann Horn <jannh@google.com>,
Amir Goldstein <amir73il@gmail.com>,
Aleksa Sarai <cyphar@cyphar.com>,
Linux API <linux-api@vger.kernel.org>,
Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH RERESEND v9 0/9] fs: interface for directly reading/writing compressed data
Date: Tue, 18 May 2021 12:21:00 -0400 [thread overview]
Message-ID: <YKPpbEuRmxQQ89si@mit.edu> (raw)
In-Reply-To: <YKN88AbnmW73uRPw@relinquished.localdomain>
On Tue, May 18, 2021 at 01:38:08AM -0700, Omar Sandoval wrote:
> 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.
Well, practically speaking, we would need to have a way to extract out
the encrypted file name information; and given that an encrypted file
could have hard links, we need to be able to obtain the encrypted file
name information for the dentry that was used to open that file. This
arguably should be separate from the encryption information for data
stream itself, so if we want to handwave how we fetch the encrypted
filename info (maybe some magic ioctl, or maybe via using some kind of
magic RWF flag used for reading encrypted directories that are opened
via O_DIRECTORY, which sorta-works like readdir() but also returns
some additional metadata information for each directory entry), sure
it should be possible to use your proposed interface as a starting
point.
I'm not sure we want to try to design all of the details of how to get
the encrypted data plus encryption metadata for the data stream, but
in theory, so long as there is a way to get the encryption metadata,
sure, it could work. One other approach is to just abuse the xattr
interface, the way we do with Posix ACL's and Capabilities, where the
on-disk format and the format used when we query a file's ACL via the
xattr interface don't necessary have to be identical. I'm sure that
will result in howls of outrage in some quarters, but this is
something for which we have a precedent.
Cheers,
- Ted
next prev parent reply other threads:[~2021-05-18 16:21 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
2021-05-18 16:21 ` Theodore Y. Ts'o [this message]
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:
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=YKPpbEuRmxQQ89si@mit.edu \
--to=tytso@mit.edu \
--cc=amir73il@gmail.com \
--cc=cyphar@cyphar.com \
--cc=david@fromorbit.com \
--cc=ebiggers@kernel.org \
--cc=hch@infradead.org \
--cc=jaegeuk@kernel.org \
--cc=jannh@google.com \
--cc=kernel-team@fb.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=osandov@osandov.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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).