Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <7b35f666-b474-9628-1cc4-7b8fc35e5074@dorminy.me>
Date:   Mon, 25 Jul 2022 22:13:12 -0400
MIME-Version: 1.0
Subject: Re: [PATCH RFC 2/4] fscrypt: add flag allowing partially-encrypted
 directories
Content-Language: en-US
To:     Eric Biggers <ebiggers@kernel.org>
Cc:     "Theodore Y . Ts'o" <tytso@mit.edu>,
        Jaegeuk Kim <jaegeuk@kernel.org>,
        linux-fscrypt@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-btrfs@vger.kernel.org, osandov@osandov.com,
        kernel-team@fb.com
References: <cover.1658623235.git.sweettea-kernel@dorminy.me>
 <0508dac7fd6ec817007c5e21a565d1bb9d4f4921.1658623235.git.sweettea-kernel@dorminy.me>
 <Yt7zsMGrxwKiM+GH@sol.localdomain>
From:   Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
In-Reply-To: <Yt7zsMGrxwKiM+GH@sol.localdomain>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


>> diff --git a/include/linux/fscrypt.h b/include/linux/fscrypt.h
>> index 6020b738c3b2..fb48961c46f6 100644
>> --- a/include/linux/fscrypt.h
>> +++ b/include/linux/fscrypt.h
>> @@ -102,6 +102,8 @@ struct fscrypt_nokey_name {
>>    * pages for writes and therefore won't need the fscrypt bounce page pool.
>>    */
>>   #define FS_CFLG_OWN_PAGES (1U << 1)
>> +/* The filesystem allows partially encrypted directories/files. */
>> +#define FS_CFLG_ALLOW_PARTIAL (1U << 2)
> 
> I'm very confused about what the semantics of this are.  So a directory will be
> able to contain both encrypted and unencrypted filenames?  If so, how will it be
> possible to distinguish between them? Or is it just both encrypted and
> unencrypted files (which is actually already possible, in the case where
> encrypted files are moved into an unencrypted directory)?  What sort of metadata
> is stored with the parent directory?
Yes, a directory for a filesystem with this flag could have both 
encrypted and unencrypted filenames.

When a directory switches to encrypted, the filesystem can get and store 
a fscrypt_context for it, as though it were a new directory. All new 
filenames for that directory will be encrypted, as will any filename 
lookup requests, by fscrypt_prepare_filename() since the directory has a 
context.

When a request for a lookup of a name in that directory comes in, it'll 
be an encrypted or nokey name; the directory can be searched for both 
the encrypted and unencrypted versions of that name. I don't think any 
filename collisions can result, as any encrypted filename which happens 
to match a plaintext filename will be detected as a collision when it's 
first added.

> 
> Please note that any new semantics and APIs will need to be documented in
> Documentation/filesystems/fscrypt.rst.
Good point.

Thanks!

Sweet Tea