Bug 1556757 - Subpath volume mount does not receive setgid by fsGroup
Summary: Subpath volume mount does not receive setgid by fsGroup
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Storage
Version: 3.9.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 3.9.z
Assignee: Jan Safranek
QA Contact: Jianwei Hou
URL:
Whiteboard:
Depends On:
Blocks: 1582610
TreeView+ depends on / blocked
 
Reported: 2018-03-15 08:29 UTC by Jianwei Hou
Modified: 2018-05-25 18:39 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1582610 (view as bug list)
Environment:
Last Closed: 2018-05-17 06:42:42 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:1566 0 None None None 2018-05-17 06:43:12 UTC

Description Jianwei Hou 2018-03-15 08:29:47 UTC
Description of problem:
The mount path of subpath does not get the setgid bit by fsGroup.

Version-Release number of selected component (if applicable):
openshift v3.9.9
kubernetes v1.9.1+a0ce1bc657
etcd 3.2.16

How reproducible:
Very

Steps to Reproduce:
1. Create a Pod with emptyDir volume
kind: Pod
apiVersion: v1
metadata: { name: "subpath" }
spec:
  volumes:
    - { name: "direct",  emptyDir: {}}
    - { name: "subpath", emptyDir: {}}
  securityContext:
    fsGroup: 100
    # games(35) is member in group users(100)
    runAsUser: 35
  containers:
    - image: aosqe/hello-openshift
      name: show
      volumeMounts:
        - name: "direct"
          mountPath: "/mnt/direct"
        - name: "subpath"
          mountPath: "/mnt/subpath"
          subPath: "a"
2. oc rsh kind: Pod
apiVersion: v1
metadata: { name: "subpath" }
spec:
  volumes:
    - { name: "direct",  emptyDir: {}}
    - { name: "subpath", emptyDir: {}}
  securityContext:
    fsGroup: 100
    # games(35) is member in group users(100)
    runAsUser: 35
  containers:
    - image: aosqe/hello-openshift
      name: show
      volumeMounts:
        - name: "direct"
          mountPath: "/mnt/direct"
        - name: "subpath"
          mountPath: "/mnt/subpath"
          subPath: "a"
2. oc exec subpath -- ls /mnt -l 

Actual results:
# oc exec subpath -- ls /mnt -l      
total 0
drwxrwsrwx    2 root     users            6 Mar 15 08:09 direct
drwxrwxrwx    2 root     users            6 Mar 15 08:09 subpath

Noticed the setgid bit is x instead of s.

Expected results:
The subpath mount path should have setgid bit.

Comment 1 Hemant Kumar 2018-03-15 12:39:10 UTC
This might be because recursive chmod of volume happens before subpath mount is created.

Comment 2 Jan Safranek 2018-03-16 13:46:00 UTC
The last security fixes seem to be cause of this.

Comment 3 Jan Safranek 2018-03-16 15:20:19 UTC
The reason is Fchmod in doSafeMakeDir():

https://github.com/openshift/origin/blob/77f8b2956b44a2ccb81f2805ae7f57247c03d8d2/vendor/k8s.io/kubernetes/pkg/util/mount/mount_linux.go#L998

	if err = syscall.Fchmod(parentFD, uint32(perm)&uint32(os.ModePerm)); err != nil {
		return fmt.Errorf("chmod %q failed: %s", currentPath, err)
	}


There are two issues:
- "perm&os.ModePerm" filters out sticky and SUID/SGID bits, which is wrong
- os.FileMode is not what fchmod() syscall expects - SUID/SGID/sticky flags are on different bits in os.FileMode and fchmod() argument.

Comment 4 Jan Safranek 2018-03-16 15:36:57 UTC
Opened issue upstream: https://github.com/kubernetes/kubernetes/issues/61283

Comment 5 Jan Safranek 2018-04-04 15:13:36 UTC
fixed by https://github.com/openshift/origin/pull/19010

Comment 7 Jianwei Hou 2018-04-17 07:07:58 UTC
Verfied on v3.9.20, this is fixed.

Comment 9 Jianwei Hou 2018-04-27 06:22:35 UTC
Verified on 3.9.24

Comment 12 errata-xmlrpc 2018-05-17 06:42:42 UTC
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/RHBA-2018:1566


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