Bug 14053 - vfs_ceph (libcephfs) denies access when permitted via supplementary group membership
Summary: vfs_ceph (libcephfs) denies access when permitted via supplementary group mem...
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: David Disseldorp
QA Contact: Samba QA Contact
Depends on:
Reported: 2019-07-25 13:51 UTC by David Disseldorp
Modified: 2023-12-27 10:48 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description David Disseldorp 2019-07-25 13:51:01 UTC
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.
Comment 1 Shachar Sharon 2023-12-27 10:48:39 UTC
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: