29 Jul
2019
29 Jul
'19
8:21 p.m.
On Thu, 25 Jul 2019 14:34:13 -0400, Jeff Layton wrote:
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
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/035a1785ec73d803fead42c7240df01b755a81…
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?