Bug 1501029 - setting storage.owner-gid should also change the mode to have setgid
Summary: setting storage.owner-gid should also change the mode to have setgid
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: posix
Version: mainline
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Raghavendra Talur
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-10-12 05:14 UTC by Raghavendra Talur
Modified: 2019-06-20 05:08 UTC (History)
4 users (show)

Fixed In Version: glusterfs-5.x
Clone Of:
Environment:
Last Closed: 2019-06-20 05:08:29 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Raghavendra Talur 2017-10-12 05:14:24 UTC
Description of problem:

When storage.owner-uid and storage.owner-gid options are used, the
    expectation is that all the dirs created in the volume should allow
    every member of the group to write. However, that is not possible
    without this patch. Here is an example

    1. say we have a group writegroup
    2. we have user1 and user2 in the group
    3. create a volume by providing writegroup's gid as storage.owner-gid
    4. as user1, create files and dirs in the volume, it works
    5. as user2, creates files and dirs in the root of the volume, it works
    6. as user2, create files and dirs in the dirs created by user1 in step 4,
       it fails with permission denied although it should succeed.

Comment 1 Worker Ant 2017-10-12 05:24:06 UTC
REVIEW: https://review.gluster.org/18496 (posix: set mode bits to inherit owner/group) posted (#1) for review on master by Raghavendra Talur (rtalur)

Comment 2 Worker Ant 2017-10-12 10:47:50 UTC
REVIEW: https://review.gluster.org/18496 (posix: set mode bits to inherit owner/group) posted (#2) for review on master by Raghavendra Talur (rtalur)

Comment 3 Niels de Vos 2017-10-12 14:55:08 UTC
Please see if this is a duplicate of https://github.com/gluster/glusterfs/issues/301

Comment 4 Raghavendra Talur 2017-10-17 10:08:05 UTC
Niels,

I have the same question. I am not sure if solves all the problems listed in issue 301. Do you think we need umask if gid and inheritance is fixed.

Comment 5 Niels de Vos 2017-10-17 11:22:09 UTC
It is already possible (though not through the Gluster CLI) to inherit the group ownership on new files/directories. This can be done with ACLs or (depending on the environment) with 'chmod g+s ...'.

It is still crucial that the umask is set correctly too. The 0644 mode (umask 0022) it often a default for newly created files, and even if the group-owner is set correctly, members of that group will not be able to write to the file.

Depending what the actual feature request here is, issue 301 might be a more suitable approach. If, however configuring the permissions solely though the Gluster CLI is a requirement, then adjusting the umask/mode when storage.owner-gid is set will needed as well.

The request in 301 is a little more flexible, as the group-owner can be different between subdirectories on the volume (w/ ACL and "chmod +s"). storage.owner-gid is set per volume, which makes it more restrictive in its usage (different teams/departments/projects can not share the same Gluster volume if they have their own dedicated owner-gid).

Comment 6 Amar Tumballi 2019-06-20 05:08:29 UTC
https://review.gluster.org/18955


Note You need to log in before you can comment on or make changes to this bug.