+++ 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)
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)
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>
REVIEW: http://review.gluster.org/12052 (features/shard: Fix permission issues) posted (#1) for review on release-3.7 by Krutika Dhananjay (kdhananj)
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