From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BAA45C43460 for ; Tue, 18 May 2021 16:21:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 874E061285 for ; Tue, 18 May 2021 16:21:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350583AbhERQWm (ORCPT ); Tue, 18 May 2021 12:22:42 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:40807 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1350575AbhERQWl (ORCPT ); Tue, 18 May 2021 12:22:41 -0400 Received: from callcc.thunk.org (96-72-84-49-static.hfc.comcastbusiness.net [96.72.84.49] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 14IGL0w8021834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 May 2021 12:21:01 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 3B003420119; Tue, 18 May 2021 12:21:00 -0400 (EDT) Date: Tue, 18 May 2021 12:21:00 -0400 From: "Theodore Y. Ts'o" To: Omar Sandoval 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 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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