On Mon, 2020-09-14 at 18:41 -0700, Eric Biggers wrote:
> On Mon, Sep 14, 2020 at 03:17:03PM -0400, Jeff Layton wrote:
> > + } else {
> > + int err;
> > + struct fscrypt_name fname = { };
> > + int len;
> > + char buf[FSCRYPT_BASE64_CHARS(NAME_MAX)];
> > +
> > + dget(parent);
> > + spin_unlock(&cur->d_lock);
> > +
> > + err = fscrypt_setup_filename(d_inode(parent), &cur->d_name, 1, &fname);
> > + if (err) {
> > + dput(parent);
> > + dput(cur);
> > + return ERR_PTR(err);
> > + }
>
> It's still not clear how no-key names are handled here (or if they are even
> possible here).
>
They're not really handled yet. We need support in the MDS for it, which
is being worked on by Xiubo (cc'ed):
https://tracker.ceph.com/issues/47162
For now, working with names > ~149 characters can leave you with bad
dentries that the client may not be able to work with if you don't have
the key.
It sounds like we'll probably need to stabilize some version of the
nokey name so that we can allow the MDS to look them up. Would it be a
problem for us to use the current version of the nokey name format for
this, or would it be better to come up with some other distinct format
for this?
Using the current version of the nokey name is simple as we can just
pass it as-is to the MDS if someone is working in a directory w/o keys.
> > +
> > + /* base64 encode the encrypted name */
> > + len = fscrypt_base64_encode(fname.disk_name.name, fname.disk_name.len, buf);
> > + pos -= len;
> > + if (pos < 0) {
> > + dput(parent);
> > + fscrypt_free_filename(&fname);
> > + break;
> > + }
> > + memcpy(path + pos, buf, len);
> > + dout("non-ciphertext name = %.*s\n", len, buf);
> > + fscrypt_free_filename(&fname);
>
> This says "non-ciphertext name", which suggest that it's a plaintext name. But
> actually it's a base64-encoded ciphertext name.
>
Thanks. I fixed the comment.
--
Jeff Layton <jlayton@xxxxxxxxxx>
