libcephfs and supplimentary groups

[David Disseldorp]

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