Bug 1253151 - Sharding - Individual shards' ownership differs from that of the original file
Sharding - Individual shards' ownership differs from that of the original file
Status: CLOSED CURRENTRELEASE
Product: GlusterFS
Classification: Community
Component: sharding (Show other bugs)
3.7.3
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Krutika Dhananjay
bugs@gluster.org
: Triaged
Depends On: 1251824
Blocks: glusterfs-3.7.4
  Show dependency treegraph
 
Reported: 2015-08-13 02:44 EDT by Krutika Dhananjay
Modified: 2015-09-09 05:39 EDT (History)
1 user (show)

See Also:
Fixed In Version: glusterfs-3.7.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1251824
Environment:
Last Closed: 2015-09-09 05:39:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Krutika Dhananjay 2015-08-13 02:44:55 EDT
+++ This bug was initially created as a clone of Bug #1251824 +++

Description of problem:
When it comes to creating new shards (this happens as of today during writev() and readv()), the shard translator uses uid and gid of the requesting process (frame->root->{uid,gid}) to create the participant shards of a write or a read request. Sometimes _even_ when a non-root user owns and operates on a sharded file, the participant shards are found to be owned by root:root in the backend.
This is because write-behind winds a collated writev with uid,gid=0 (for all we know the different writes that write-behind collates could have come from different user processes). Here the assumption is that if open() on a file has already succeeded for a given file and an fd is returned, subsequent change of permissions shall have no effect on the writes that are performed through this particular fd.

Even so, shard translator should be creating participant shards with the same uid and gid as that of the original owner of the actual file.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

--- Additional comment from Krutika Dhananjay on 2015-08-10 10:00:10 EDT ---

http://review.gluster.org/#/c/11874/

--- Additional comment from Anand Avati on 2015-08-13 02:34:51 EDT ---

REVIEW: http://review.gluster.org/11874 (features/shard: Ensure shards are owned by the same owner/group as the original file) posted (#3) for review on master by Krutika Dhananjay (kdhananj@redhat.com)
Comment 1 Anand Avati 2015-08-14 12:02:35 EDT
REVIEW: http://review.gluster.org/11927 (features/shard: Ensure shards are owned by the same owner/group as the original file) posted (#1) for review on release-3.7 by Krutika Dhananjay (kdhananj@redhat.com)
Comment 2 Anand Avati 2015-08-19 05:27:40 EDT
COMMIT: http://review.gluster.org/11927 committed in release-3.7 by Pranith Kumar Karampuri (pkarampu@redhat.com) 
------
commit 5d9668dbb4f20ec7ce385e1d348e46b1425e4e84
Author: Krutika Dhananjay <kdhananj@redhat.com>
Date:   Mon Aug 10 19:10:21 2015 +0530

    features/shard: Ensure shards are owned by the same owner/group as the original file
    
            Backport of: http://review.gluster.org/#/c/11874/
    
    Change-Id: I8c905917430c32eb2e6573968722920d3b27fb55
    BUG: 1253151
    Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
    Reviewed-on: http://review.gluster.org/11927
    Tested-by: Gluster Build System <jenkins@build.gluster.com>
    Tested-by: NetBSD Build System <jenkins@build.gluster.org>
    Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
Comment 3 Anand Avati 2015-08-31 00:41:40 EDT
REVIEW: http://review.gluster.org/12052 (features/shard: Fix permission issues) posted (#1) for review on release-3.7 by Krutika Dhananjay (kdhananj@redhat.com)
Comment 4 Kaushal 2015-09-09 05:39:36 EDT
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.4, please open a new bug report.

glusterfs-3.7.4 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/12496
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

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