Bug 1253151

Summary: Sharding - Individual shards' ownership differs from that of the original file
Product: [Community] GlusterFS Reporter: Krutika Dhananjay <kdhananj>
Component: shardingAssignee: Krutika Dhananjay <kdhananj>
Status: CLOSED CURRENTRELEASE QA Contact: bugs <bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.7.3CC: bugs
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: glusterfs-3.7.4 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1251824 Environment:
Last Closed: 2015-09-09 09:39:36 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:
Bug Depends On: 1251824    
Bug Blocks: 1248533    

Description Krutika Dhananjay 2015-08-13 06:44:55 UTC 
+++ 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)
Comment 1 Anand Avati 2015-08-14 16:02:35 UTC 
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)
Comment 2 Anand Avati 2015-08-19 09:27:40 UTC 
COMMIT: http://review.gluster.org/11927 committed in release-3.7 by Pranith Kumar Karampuri (pkarampu) 
------
commit 5d9668dbb4f20ec7ce385e1d348e46b1425e4e84
Author: Krutika Dhananjay <kdhananj>
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>
    Reviewed-on: http://review.gluster.org/11927
    Tested-by: Gluster Build System <jenkins.com>
    Tested-by: NetBSD Build System <jenkins.org>
    Reviewed-by: Pranith Kumar Karampuri <pkarampu>
Comment 3 Anand Avati 2015-08-31 04:41:40 UTC 
REVIEW: http://review.gluster.org/12052 (features/shard: Fix permission issues) posted (#1) for review on release-3.7 by Krutika Dhananjay (kdhananj)
Comment 4 Kaushal 2015-09-09 09:39:36 UTC 
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