Bug 1501029
| Summary: | setting storage.owner-gid should also change the mode to have setgid | ||
|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | Raghavendra Talur <rtalur> |
| Component: | posix | Assignee: | Raghavendra Talur <rtalur> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | mainline | CC: | atumball, bugs, ndevos, rtalur |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | glusterfs-5.x | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-06-20 05:08:29 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
REVIEW: https://review.gluster.org/18496 (posix: set mode bits to inherit owner/group) posted (#1) for review on master by Raghavendra Talur (rtalur) REVIEW: https://review.gluster.org/18496 (posix: set mode bits to inherit owner/group) posted (#2) for review on master by Raghavendra Talur (rtalur) Please see if this is a duplicate of https://github.com/gluster/glusterfs/issues/301 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. 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). |
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.