Re: [RFC] odd check in ceph_encode_encrypted_dname()

[Luis Henriques <luis@igalia.com>]

On Fri, Feb 14 2025, Al Viro wrote:

> On Fri, Feb 14, 2025 at 02:47:56AM +0000, Al Viro wrote:
>
> [snip]
>
>> Am I missing something subtle here?  Can elen be non-positive at that point?

It has been a while since I last looked into this code, so the details are
quite foggy.  I don't think you're missing something and that '(elen > 0)'
test could be dropped.  Unfortunately, I can only tell that through code
analysis -- I don't have a test environment anymore where I could try
that.

> Another fun question: for dentries with name of form _<something>_<inumber>
> we end up looking at fscrypt_has_encryption_key() not for the parent,
> but for inode with inumber encoded in dentry name.  Fair enough, but...
> what happens if we run into such dentry in ceph_mdsc_build_path()?
>
> There the call of ceph_encode_encrypted_fname() is under
> 	if (fscrypt_has_encryption_key(d_inode(parent)))
>
> Do we need the keys for both?

I'm not sure I totally understand your question, but here are my thoughts:
if we have the key for the parent, then we *do* have the key for an inode
under that encrypted subtree.  This is because AFAIR we can not have
nested encryption.  Thus, the call to ceph_encode_encrypted_fname()
*should* be OK.

But I'm CC'ing Jeff as he wrote most of the cephfs fscrypt code and he
might correct me.  Or maybe he has a better memory than I do.

Cheers,
-- 
Luís