Hide Forgot
Description of problem: The permission of mountPath in configmap volume should be "1777" Version-Release number of selected component (if applicable): # openshift version openshift v3.4.0.33+71c05b2 kubernetes v1.4.0+776c994 etcd 3.1.0-rc.0 How reproducible: Always Steps to Reproduce: 1. oc login https://$host_name:8443 2. Create a configmap "special-config" apiVersion: v1 kind: ConfigMap metadata: name: special-config data: special.how: very special.type: charm 3. Add login user to "anyuid" policy, in order to workaround bug: https://bugzilla.redhat.com/show_bug.cgi?id=1384458 # oadm policy add-scc-to-user anyuid chezhang 4. Create a pod by default permission mode in configmap volume # oc create -f configmap-permission-pod.yaml # cat configmap-permission-pod.yaml apiVersion: v1 kind: Pod metadata: name: configmap-permission-pod spec: containers: - name: configmap-permission-pod image: redis volumeMounts: - name: config-volume mountPath: "/etc/config" volumes: - name: config-volume configMap: name: special-config defaultMode: 0400 5. Check permission of directory "/etc/config" in configmap volume # oc exec -it configmap-permission-pod -- sh -c "stat -c %a /etc/config" Actual results: Can get key/value via "oc exec -it $pod", but cannot get value via "oc env pods" 5. # oc exec -it configmap-permission-pod -- sh -c "stat -c %a /etc/config" 777 Expected results: 5. # oc exec -it configmap-permission-pod -- sh -c "stat -c %a /etc/config" 1777 addition info: Tested in downward API and secret volume, both have "1777" permission. 1. Downward API: $ oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/pods/permission-data/dapi-permission-pod.yaml pod "dapi-permission-pod" created $ oc get pod | grep dapi-permission-pod dapi-permission-pod 1/1 Running 0 16s $ oc exec -it dapi-permission-pod -- sh -c "stat -c %a /var/tmp/podinfo" 1777 2. Secret: $ oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/secrets/secret.yaml secret "test-secret" created $ oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/pods/permission-data/secret-permission-pod.yaml pod "secret-permission-pod" created $ oc get pod | grep secret-permission-pod secret-permission-pod 1/1 Running 0 14s $ oc exec -it secret-permission-pod -- sh -c "stat -c %a /etc/foo" 1777
I can recreate. Worth noting that without the anyuid, 2777 is returned $ oc version oc v1.5.0-alpha.0+5ffd95f-262-dirty kubernetes v1.4.0+776c994 features: Basic-Auth Server https://10.42.10.23:8443 openshift v1.5.0-alpha.0+5ffd95f-262-dirty kubernetes v1.4.0+776c994 $ oc login Authentication required for https://10.42.10.23:8443 (openshift) Username: demo Password: Login successful. You have one project on this server: "demo" Using project "demo". $ oc create -f pod.yaml pod "configmap-permission-pod" created $ oc exec -it configmap-permission-pod -- sh -c "stat -c %a /etc/config" 2777 [sjennings@cerebellum origin]$ oc login -u system:admin Logged into "https://10.42.10.23:8443" as "system:admin" using existing credentials. You have access to the following projects and can switch between them with 'oc project <projectname>': default * demo kube-system openshift openshift-infra Using project "demo". [sjennings@cerebellum origin]$ oadm policy add-scc-to-user anyuid demo [sjennings@cerebellum origin]$ oc login Authentication required for https://10.42.10.23:8443 (openshift) Username: demo Password: Login successful. You have one project on this server: "demo" Using project "demo". [sjennings@cerebellum origin]$ oc delete pod --all pod "configmap-permission-pod" deleted [sjennings@cerebellum origin]$ oc get pod NAME READY STATUS RESTARTS AGE configmap-permission-pod 1/1 Terminating 0 1m [sjennings@cerebellum origin]$ oc get pod No resources found. [sjennings@cerebellum origin]$ oc create -f pod.yaml pod "configmap-permission-pod" created [sjennings@cerebellum origin]$ oc exec -it configmap-permission-pod -- sh -c "stat -c %a /etc/config" 777
The reason for this is the secrets and downward API use memory backend emptydirs under the covers where configmaps currently use disk backed emptydirs. tmpfs mounts have the restricted delete bit set by default. $ mount -t tmpfs none tmp $ ls -al tmp total 8 drwxrwxrwt. 2 root root 40 Jan 4 16:17 . $ umount tmp $ mount -t tmpfs -o mode=0777 none tmp $ ls -ald tmp drwxrwxrwx. 2 root root 40 Jan 4 16:19 tmp I think the real "fix" for this (if one is needed at all) is to make configmaps memory backed. There is even a comment in the code to this effect: func wrappedVolumeSpec() volume.Spec { // This is the spec for the volume that this plugin wraps. return volume.Spec{ // This should be on a tmpfs instead of the local disk; the problem is // charging the memory for the tmpfs to the right cgroup. We should make // this a tmpfs when we can do the accounting correctly. Volume: &v1.Volume{VolumeSource: v1.VolumeSource{EmptyDir: &v1.EmptyDirVolumeSource{}}}, } } If that comment is true, the damage is already done, to a much larger degree, with memory backed emptydirs being allowed. I think they should just be memory backed.
After talking with Derek there is a reason the configmaps are disk backed detailed here: https://github.com/kubernetes/kubernetes/pull/25306#issuecomment-217712626 While the restricted-delete bit being set on secrets and downward API is a side effect of being tmpfs mounts, and the difference between secrets and configmaps might be unexpected, there really is no bug here.
Hello, Still, there is a bug probably. I see report on kubernetes 1.4 that are apparently fixed in 1.6. I suspect that the file behind is also 777 and not only the link and that the mode/defaultmode is effectivelly not honored. This make the configmap useless. For instance trying to inject a file in /etc/my.cnf.d/ works but the permissions of the file are incorrect and mysql complains about it. Regards, Marc