All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: ceph-devel@vger.kernel.org, lhenriques@suse.de,
	xiubli@redhat.com, linux-fsdevel@vger.kernel.org,
	linux-fscrypt@vger.kernel.org, dhowells@redhat.com
Subject: Re: [RFC PATCH v7 15/24] ceph: add encrypted fname handling to ceph_mdsc_build_path
Date: Mon, 12 Jul 2021 08:36:13 -0400	[thread overview]
Message-ID: <7c57504514c107aa1cde04b566575a6e1461ecd5.camel@kernel.org> (raw)
In-Reply-To: <YOt2cVJLEXt88SVJ@quark.localdomain>

On Sun, 2021-07-11 at 17:53 -0500, Eric Biggers wrote:
> On Fri, Jun 25, 2021 at 09:58:25AM -0400, Jeff Layton wrote:
> > +/*
> > + * We want to encrypt filenames when creating them, but the encrypted
> > + * versions of those names may have illegal characters in them. To mitigate
> > + * that, we base64 encode them, but that gives us a result that can exceed
> > + * NAME_MAX.
> > + *
> > + * Follow a similar scheme to fscrypt itself, and cap the filename to a
> > + * smaller size. If the cleartext name is longer than the value below, then
> > + * sha256 hash the remaining bytes.
> > + *
> > + * 189 bytes => 252 bytes base64-encoded, which is <= NAME_MAX (255)
> > + */
> > +#define CEPH_NOHASH_NAME_MAX (189 - SHA256_DIGEST_SIZE)
> 
> Shouldn't this say "If the ciphertext name is longer than the value below", not
> "If the cleartext name is longer than the value below"?
> 
> It would also be helpful if the above comment mentioned that when the hashing is
> done, the real encrypted name is stored separately.
> 
> > +#if IS_ENABLED(CONFIG_FS_ENCRYPTION)
> > +static int encode_encrypted_fname(const struct inode *parent, struct dentry *dentry, char *buf)
> > +{
> > +	u32 len;
> > +	int elen;
> > +	int ret;
> > +	u8 *cryptbuf;
> > +
> > +	WARN_ON_ONCE(!fscrypt_has_encryption_key(parent));
> > +
> > +	/*
> > +	 * convert cleartext dentry name to ciphertext
> > +	 * if result is longer than CEPH_NOKEY_NAME_MAX,
> > +	 * sha256 the remaining bytes
> > +	 *
> > +	 * See: fscrypt_setup_filename
> > +	 */
> > +	if (!fscrypt_fname_encrypted_size(parent, dentry->d_name.len, NAME_MAX, &len))
> > +		return -ENAMETOOLONG;
> > +
> > +	/* If we have to hash the end, then we need a full-length buffer */
> > +	if (len > CEPH_NOHASH_NAME_MAX)
> > +		len = NAME_MAX;
> > +
> > +	cryptbuf = kmalloc(len, GFP_KERNEL);
> > +	if (!cryptbuf)
> > +		return -ENOMEM;
> > +
> > +	ret = fscrypt_fname_encrypt(parent, &dentry->d_name, cryptbuf, len);
> > +	if (ret) {
> > +		kfree(cryptbuf);
> > +		return ret;
> > +	}
> > +
> > +	/* hash the end if the name is long enough */
> > +	if (len > CEPH_NOHASH_NAME_MAX) {
> > +		u8 hash[SHA256_DIGEST_SIZE];
> > +		u8 *extra = cryptbuf + CEPH_NOHASH_NAME_MAX;
> > +
> > +		/* hash the extra bytes and overwrite crypttext beyond that point with it */
> > +		sha256(extra, len - CEPH_NOHASH_NAME_MAX, hash);
> > +		memcpy(extra, hash, SHA256_DIGEST_SIZE);
> > +		len = CEPH_NOHASH_NAME_MAX + SHA256_DIGEST_SIZE;
> > +	}
> 
> When the ciphertext name is longer than CEPH_NOHASH_NAME_MAX, why is the
> filename being padded all the way to NAME_MAX?  That can produce a totally
> different ciphertext from that produced by get_fscrypt_altname() in the next
> patch.
> 

Oh, I misunderstood the meaning of the last parameter to
fscrypt_fname_encrypt. I had thought that was the length of the target
buffer, but it's not -- it's the length of the resulting filename (which
we need to precompute). I'll fix that up.

> The logical thing to do would be to do the encryption in the same way as
> get_fscrypt_altname(), and then replace any bytes beyond CEPH_NOHASH_NAME_MAX
> with their hash.
> 

That might make more sense.

> > +
> > +	/* base64 encode the encrypted name */
> > +	elen = fscrypt_base64_encode(cryptbuf, len, buf);
> > +	kfree(cryptbuf);
> > +	dout("base64-encoded ciphertext name = %.*s\n", len, buf);
> > +	return elen;
> 
> The argument to dout() should be elen, not len.
> 

Will fix, thanks.
-- 
Jeff Layton <jlayton@kernel.org>


  reply	other threads:[~2021-07-12 12:36 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-25 13:58 [RFC PATCH v7 00/24] ceph+fscrypt: context, filename and symlink support Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 01/24] vfs: export new_inode_pseudo Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 02/24] fscrypt: export fscrypt_base64_encode and fscrypt_base64_decode Jeff Layton
2021-07-11 17:40   ` Eric Biggers
2021-07-12 11:55     ` Jeff Layton
2021-07-12 14:22       ` Eric Biggers
2021-07-12 14:32         ` Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 03/24] fscrypt: export fscrypt_fname_encrypt and fscrypt_fname_encrypted_size Jeff Layton
2021-07-11 17:43   ` Eric Biggers
2021-06-25 13:58 ` [RFC PATCH v7 04/24] fscrypt: add fscrypt_context_for_new_inode Jeff Layton
2021-07-11 17:44   ` Eric Biggers
2021-06-25 13:58 ` [RFC PATCH v7 05/24] ceph: preallocate inode for ops that may create one Jeff Layton
2021-07-07  3:37   ` Xiubo Li
2021-07-07 12:05     ` Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 06/24] ceph: parse new fscrypt_auth and fscrypt_file fields in inode traces Jeff Layton
2021-07-07  3:53   ` Xiubo Li
2021-07-07 12:09     ` Jeff Layton
2021-07-07 12:46       ` Xiubo Li
2021-07-07 10:47   ` Luis Henriques
2021-07-07 11:19     ` Xiubo Li
2021-07-07 12:19       ` Jeff Layton
2021-07-07 14:32         ` Luis Henriques
2021-07-07 14:56           ` Luis Henriques
2021-07-08  2:56             ` Xiubo Li
2021-07-08 11:26             ` Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 07/24] ceph: add fscrypt_* handling to caps.c Jeff Layton
2021-07-07  7:20   ` Xiubo Li
2021-07-07 12:02     ` Jeff Layton
2021-07-07 12:47       ` Xiubo Li
2021-07-11 23:00   ` Eric Biggers
2021-07-12 13:22     ` Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 08/24] ceph: add ability to set fscrypt_auth via setattr Jeff Layton
2021-07-07  8:11   ` Xiubo Li
2021-07-07 12:10     ` Jeff Layton
2021-07-07 10:47   ` Luis Henriques
2021-07-07 12:25     ` Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 09/24] ceph: crypto context handling for ceph Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 10/24] ceph: implement -o test_dummy_encryption mount option Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 11/24] ceph: add routine to create fscrypt context prior to RPC Jeff Layton
2021-07-07 10:48   ` Luis Henriques
2021-07-07 12:29     ` Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 12/24] ceph: add fscrypt ioctls Jeff Layton
2021-07-08  7:30   ` Xiubo Li
2021-07-08 11:26     ` Jeff Layton
2021-07-08 11:32       ` Xiubo Li
2021-06-25 13:58 ` [RFC PATCH v7 13/24] ceph: decode alternate_name in lease info Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 14/24] ceph: make ceph_msdc_build_path use ref-walk Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 15/24] ceph: add encrypted fname handling to ceph_mdsc_build_path Jeff Layton
2021-07-11 22:53   ` Eric Biggers
2021-07-12 12:36     ` Jeff Layton [this message]
2021-06-25 13:58 ` [RFC PATCH v7 16/24] ceph: send altname in MClientRequest Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 17/24] ceph: properly set DCACHE_NOKEY_NAME flag in lookup Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 18/24] ceph: make d_revalidate call fscrypt revalidator for encrypted dentries Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 19/24] ceph: add helpers for converting names for userland presentation Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 20/24] ceph: add fscrypt support to ceph_fill_trace Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 21/24] ceph: add support to readdir for encrypted filenames Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 22/24] ceph: create symlinks with encrypted and base64-encoded targets Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 23/24] ceph: make ceph_get_name decrypt filenames Jeff Layton
2021-06-25 13:58 ` [RFC PATCH v7 24/24] ceph: add a new ceph.fscrypt.auth vxattr 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=7c57504514c107aa1cde04b566575a6e1461ecd5.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=dhowells@redhat.com \
    --cc=ebiggers@kernel.org \
    --cc=lhenriques@suse.de \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=xiubli@redhat.com \
    /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.