client/fuse: handle case of renameat2 with non-zero flags

When user issues renameat(2) with non-zero flags (RENAME_EXCHANGE or
RENAME_NOREPALCE) the current code ignores those flags and treat the
call as ordinary rename. This, in turn, may yield successful rename with
wrong semantics then those expected by the caller.

Follow the same semantics as kernel's cephfs client: return -EINVAL when
having non-zero flags to renameat2 (see 'ceph_rename' at fs/ceph/dir.c).

Fixes: https://tracker.ceph.com/issues/63722
Signed-off-by: Shachar Sharon <ssharon@redhat.com>

diff --git a/src/client/fuse_ll.cc b/src/client/fuse_ll.cc
index 7f92dd668ba3eaaeb5ae78866a1f71de1e8af03c..0e2e200644de63825e2fa3c17358c7851392d820 100644 (file)
--- a/src/client/fuse_ll.cc
+++ b/src/client/fuse_ll.cc
@@ -753,6 +753,15 @@ static void fuse_ll_rename(fuse_req_t req, fuse_ino_t parent, const char *name,
 #endif
                            )
 {
+#if FUSE_VERSION >= FUSE_MAKE_VERSION(3, 0)
+  // cephfs does not support renameat2 flavors; follow same logic as done in
+  // kclient's ceph_rename()
+  if (flags) {
+    fuse_reply_err(req, get_sys_errno(CEPHFS_EINVAL));
+    return;
+  }
+#endif
+
   CephFuse::Handle *cfuse = fuse_ll_req_prepare(req);
   const struct fuse_ctx *ctx = fuse_req_ctx(req);
   UserPerm perm(ctx->uid, ctx->gid);