Bug 1402291

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