All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Henriques <luis@igalia.com>
To: Jeff Layton <jlayton@kernel.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	 ceph-devel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	 Ilya Dryomov <idryomov@gmail.com>
Subject: Re: [RFC] odd check in ceph_encode_encrypted_dname()
Date: Fri, 14 Feb 2025 16:05:42 +0000	[thread overview]
Message-ID: <87frkg7bqh.fsf@igalia.com> (raw)
In-Reply-To: <bbc3361f9c241942f44298286ba09b087a10b78b.camel@kernel.org> (Jeff Layton's message of "Fri, 14 Feb 2025 10:41:15 -0500")

[ Dropping my previous email from the CC list ]

On Fri, Feb 14 2025, Jeff Layton wrote:

> On Fri, 2025-02-14 at 03:28 +0000, 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?
>> 
>> 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?
>> 
>
> That sounds like a bug, but I don't fully recall whether snapshots have
> a special case here for some reason. Let me rephrase Al's question:
>
> If I have a snapshot dir that is prefixed with '_', why does it use a
> different filename encryption key than other snapshot dirs that don't
> start with that character?
>
> My guess here is that this code ought not overwrite "dir" with the
> result of parse_longname(), but I don't recall the significance of a
> snapshot name that starts with '_'.

This bit I _think_ I remember.  Imagine this tree structure:

   /mnt/ceph
   |-- mydir1
   |-- mydir2

If you create a snapshot in /mnt/ceph:

  mkdir /mnt/ceph/.snap/my-snapshot

you'll see this:

   /mnt/ceph
   |-- .snap
   |     |-- my-snapshot
   |-- mydir1
   |     |-- _my-snapshot_1099511627782
   |-- mydir2
         |-- _my-snapshot_1099511627782

('1099511627782' is the inode number where the snapshot was created.)

So, IIRC, when encrypting the snapshot name (the "my-snapshot" string),
you'll use key from the original inode.  That's why we need to handle
snapshot names starting with '_' differently.  And why we have a
customized base64 encoding function.

Cheers,
-- 
Luís


>         /* Handle the special case of snapshot names that start with '_' */
>         if ((ceph_snap(dir) == CEPH_SNAPDIR) && (name_len > 0) &&
>             (iname.name[0] == '_')) {
>                 dir = parse_longname(parent, iname.name, &name_len);
>                 if (IS_ERR(dir))
>                         return PTR_ERR(dir);
>                 iname.name++; /* skip initial '_' */
>         }
>         iname.len = name_len;
>
>         if (!fscrypt_has_encryption_key(dir)) {
>                 memcpy(buf, d_name->name, d_name->len);
>                 elen = d_name->len;
>                 goto out;
>         }
>
>
> -- 
> Jeff Layton <jlayton@kernel.org>
>
 

  reply	other threads:[~2025-02-14 16:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-14  2:47 [RFC] odd check in ceph_encode_encrypted_dname() Al Viro
2025-02-14  3:28 ` Al Viro
2025-02-14 14:05   ` Luis Henriques
2025-02-14 15:41   ` Jeff Layton
2025-02-14 16:05     ` Luis Henriques [this message]
2025-02-15  4:46       ` Al Viro
2025-02-15  4:47         ` [PATCH 1/2] prep for ceph_encode_encrypted_fname() fixes Al Viro
2025-02-15 12:41           ` Jeff Layton
2025-02-15  4:47         ` [PATCH 2/2] ceph: fix a race with rename() in ceph_mdsc_build_path() Al Viro
2025-02-15 12:42           ` Jeff Layton
2025-02-15 15:39         ` [RFC] odd check in ceph_encode_encrypted_dname() Luis Henriques
2025-02-17 17:56           ` Viacheslav Dubeyko
2025-02-17 18:48             ` Luis Henriques
2025-02-17 22:04               ` Viacheslav Dubeyko
2025-02-18  1:21                 ` Al Viro
2025-02-18 23:52                   ` Al Viro
2025-02-19  0:58                     ` Viacheslav Dubeyko
2025-02-19  2:18                       ` Al Viro
2025-02-19 23:22                         ` Viacheslav Dubeyko
2025-02-21  1:21                         ` Viacheslav Dubeyko
2025-02-14 15:30 ` Jeff Layton

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=87frkg7bqh.fsf@igalia.com \
    --to=luis@igalia.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=idryomov@gmail.com \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.