Bug 1315962 - Fsgroup does not work for gitrepo volume
Fsgroup does not work for gitrepo volume
Status: CLOSED ERRATA
Product: OpenShift Container Platform
Classification: Red Hat
Component: Storage (Show other bugs)
3.1.0
Unspecified Unspecified
low Severity low
: ---
: ---
Assigned To: Paul Morie
chaoyang
: Regression, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-09 02:15 EST by chaoyang
Modified: 2017-08-16 15 EDT (History)
10 users (show)

See Also:
Fixed In Version: atomic-openshift-node-3.4.1.42-1.git.0.e775fe2.el7.x86_64
Doc Type: No Doc Update
Doc Text:
undefined
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-10 01:15:47 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 chaoyang 2016-03-09 02:15:07 EST
Description of problem:
Fsgroup does not work for gitrepo volume

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

openshift v3.1.1.911
kubernetes v1.2.0-alpha.7-703-gbc4550d
etcd 2.2.5
How reproducible:
Always


Steps to Reproduce:
1.Create a pod
oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/persistent-volumes/gitrepo/gitrepo-selinux-fsgroup-test.json

2.Check pod status
NAME      READY     STATUS    RESTARTS   AGE
gitrepo   1/1       Running   0          3h

3.
/mnt/git $ id
uid=1000050000 gid=0(root) groups=123456
/mnt/git $ ls -lrt
total 0
drwxr-xr-x    3 root     root            48 Mar  8 02:41 gitrepoVolume
/mnt/git $ touch gitrepoVolume/file1
touch: gitrepoVolume/file1: Permission denied


Actual results:
group is root in the pod gitrepo

Expected results:
group id should be 123456 in the pod gitrepo



Additional info:
Comment 1 Sami Wagiaalla 2016-03-15 11:18:24 EDT
The gitrepo volume does not support ownership management. This works as expected.
Comment 2 Sami Wagiaalla 2016-03-15 11:55:46 EDT
my mistake.. it should work
Comment 4 Jeff Vance 2016-03-16 21:58:42 EDT
Just a comment related to fsGroup: 123456, and I'm not sure if the ceph-rbd plugin I used to test this supports changing the container's GID, but:

When I define fsGroup in the pod spec which uses a ceph-rbd block volume, the resulting container's GID is 0 and the fsGroup is added to the container's supplemental gids.
Comment 5 Matthew Wong 2016-08-08 17:14:38 EDT
Can't reproduce in kubernetes 1.3 looks like it was fixed by https://github.com/kubernetes/kubernetes/pull/22995
Comment 6 Jan Safranek 2017-06-28 11:13:12 EDT
I think this bug has been fixed a long time ago, at least I cannot reproduce it in atomic-openshift-node-3.4.1.42-1.git.0.e775fe2.el7.x86_64. Moving to QA to verify it in 3.6.
Comment 9 chaoyang 2017-07-24 02:22:42 EDT
It is passed on
oc v3.6.153
kubernetes v1.6.1+5115d708d7
Comment 11 errata-xmlrpc 2017-08-10 01:15:47 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:1716

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