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:
http://review.gluster.org/#/c/11874/
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/11874 (features/shard: Ensure shards are owned by the same owner/group as the original file) posted (#4) for review on master by Krutika Dhananjay (kdhananj)
REVIEW: http://review.gluster.org/11874 (features/shard: Ensure shards are owned by the same owner/group as the original file) posted (#5) for review on master by Krutika Dhananjay (kdhananj)
COMMIT: http://review.gluster.org/11874 committed in master by Pranith Kumar Karampuri (pkarampu) ------ commit 470a50b1d5017f015a1f3f3ea65a33902a02ffea 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 Change-Id: Id759af8f3ff5fd8bfa9f8121bab25722709d42b7 BUG: 1251824 Signed-off-by: Krutika Dhananjay <kdhananj> Reviewed-on: http://review.gluster.org/11874 Tested-by: NetBSD Build System <jenkins.org> Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Pranith Kumar Karampuri <pkarampu>
Moving the bug back to POST since there's one more cleanup patch to be sent against this BZ.
REVIEW: http://review.gluster.org/11992 (features/shard: Fix permission issues) posted (#1) for review on master by Krutika Dhananjay (kdhananj)
REVIEW: http://review.gluster.org/11992 (features/shard: Fix permission issues) posted (#2) for review on master by Krutika Dhananjay (kdhananj)
REVIEW: http://review.gluster.org/11992 (features/shard: Fix permission issues) posted (#4) for review on master by Pranith Kumar Karampuri (pkarampu)
COMMIT: http://review.gluster.org/11992 committed in master by Pranith Kumar Karampuri (pkarampu) ------ commit beb7abe8762ad73de104f0707949a09af847464d Author: Krutika Dhananjay <kdhananj> Date: Wed Aug 19 16:54:42 2015 +0530 features/shard: Fix permission issues This patch does the following: * reverts commit b467af0e99b39ef708420d3f7f6696b0ca618512 * changes ownership on shards under /.shard to be root:root * makes readv, writev, [f]truncate, rename, and unlink fops to perform operations on files under /.shard with frame->root->{uid,gid} as 0. This would ensure that a [f]setattr on a sharded file does not need to be called on all the shards associated with it. Change-Id: Idcfb8c0dd354b0baab6b2356d2ab83ce51caa20e BUG: 1251824 Signed-off-by: Krutika Dhananjay <kdhananj> Reviewed-on: http://review.gluster.org/11992 Reviewed-by: Pranith Kumar Karampuri <pkarampu> Tested-by: NetBSD Build System <jenkins.org> Tested-by: Gluster Build System <jenkins.com>
Fix for this BZ is already present in a GlusterFS release. You can find clone of this BZ, fixed in a GlusterFS release and closed. Hence closing this mainline BZ as well.
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.8.0, please open a new bug report. glusterfs-3.8.0 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://blog.gluster.org/2016/06/glusterfs-3-8-released/ [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user