Steps to reproduce: - create a test user which is a member of a supplementary group in addition to a primary group. - create a directory within a Samba share and set an ACL which permits traversal for the supplementary group, but doesn't allow access for the test user's uid or primary gid. - connect as the test user and attempt to traverse to the created directory. The above procedure fails if the Samba share is backed by vfs_ceph but passes if backed by a kernel CephFS mount (alongside vfs_default). I also had acl_xattr enabled for reproduction, but it shouldn't matter. The problem is that libcephfs ignores supplementary groups unless they have been explicitly set via init_gids(), ceph_mount_perms_set(), etc, while uid and gid checks fallback to geteuid() / getegid() if they haven't been initialized.
libcephfs provides the appropriate APIs to associate user's supplementary group with ceph_mount_info. This requires the following 3 steps in the right order: 1) ceph_init 2) ceph_mount_perms_set (with groups) 3) ceph_mount Current code does implicit init upon ceph_mount, with no supplementary groups associated with default UserPerm. The following MR sets things in the right order and solves this problem: https://gitlab.com/samba-team/samba/-/merge_requests/3466
Shachar, with the ceph_new module in place this is (in that new module) no longer an issue and can be finally closed, right?
Access using supplementary group membership is automatically enabled in vfs_ceph_new.c module (using libcephfs' ceph_userperm_new API), which uses the returned UserPerm* as parameter to the relevant low-level call. For the legacy vfs_ceph.c, which uses the high-level APIs there is no support for supplementary groups. IMHO this bug may be closed. Users are encouraged to switch to the new module.
Thanks for the explanation, closing as fixed.