On Thu, 25 Jul 2019 14:34:13 -0400, Jeff Layton wrote: > On Thu, 2019-07-25 at 17:07 +0200, David Disseldorp wrote: > > Hi, > > > > Without calling ceph_mount_perms_set(), libcephfs consumers such as > > Samba can rely upon UserPerm::uid() and UserPerm::gid() to fallback to > > geteuid() and setegid() respectively for things such as ACL enforcement. ^ that should be "geteuid() and getegid() ..." > > However, there is no such fallback for supplementary groups, so ACL > > checks for a user which is only permitted path access via a > > supplementary group will result in a permission denied error. > > > > Samba ticket: https://bugzilla.samba.org/show_bug.cgi?id=14053 > > > > I've written a patch to address this (it currently omits the get_gids() > > codepath): > > https://github.com/ddiss/ceph/commit/035a1785ec73d803fead42c7240df01b755a815b > > > > Does this approach make sense, or should Samba go down the > > ceph_mount_perms_set() route to avoid this bug? The latter > > would likely be problematic, as user/group details for a mount will > > remain static. > > > > I think that a better approach would be to have samba just call > ceph_mount_perms_set to set the credentials soon after forking. Is there > some reason that doesn't work here? Samba becomes root for some privileged operations where Windows would permit access. E.g. "acl group control", vfs_acl_xattr, etc. We should be able to change Samba's vfs_ceph to use the ceph_ll_X API to handle the user<->root perms switches and add corresponding geteuid()/getegid() checks in each VFS call, but IMO this is still something that should be fixed in libcephfs, to compliment the existing geteuid/getegid() fallback behaviour. Cheers, David _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
