Directories provisioned by hostPath provisioner are only writeable by root

[yuvipanda]

Is this a BUG REPORT or FEATURE REQUEST? (choose one): bug report

Please provide the following details:

Environment:

Minikube version (use minikube version): v0.21.0

• OS (e.g. from /etc/os-release): ubuntu 17.04
• VM Driver (e.g. cat ~/.minikube/machines/minikube/config.json | grep DriverName): virtualbox
• ISO version (e.g. cat ~/.minikube/machines/minikube/config.json | grep -i ISO or minikube ssh cat /etc/VERSION): minikube-v0.20.0.iso
• Install tools:
• Others:

What happened:

1. I provision a PVC
2. It is dynamically bound to a hostPath volume by the minikube provisioner
3. A pod is created that mounts the PVC
4. The process in the pod is running as uid 1000, with fsgid 1000 too
5. The process can not write to the PVC mount, since it is only writeable by root

Since we don't want to allow escalating privileges in the pod, we can't use the PVC mount at all.

What you expected to happen:

Some way of specifying in the PVC what uid / gid the hostPath should be owned by, so we can write to it.

How to reproduce it (as minimally and precisely as possible):

kubectl apply -f the following file:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: "0"
---
apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  volumes:
    - name: test 
      persistentVolumeClaim:
        claimName: test
  containers:
  - image: busybox:latest
    name: notebook
    volumeMounts: 
     - mountPath: /home/test
       name: test
    command: ["/bin/sh", "-c", "touch /home/test/hi"]
  securityContext:
    fsGroup: 1000
    runAsUser: 1000

It fails with the following output:

touch: /home/test/hi: Permission denied

If you set the fsGroup and runAsUser to 0, it succeeds.

[yuvipanda]

Perhaps an annotation for the PVC that sets ownership? Or mode?

[yuvipanda]

According to

minikube/pkg/localkube/storage_provisioner.go

Line 72 in cc64fb0

if err := os.MkdirAll(path, 0777); err != nil {

it looks like the pvc should be created with 0777 permissions, but in reality:

$ ls -lhsd pvc-d55626b9-9e3b-11e7-a572-08002772c173/
4.0K drwxr-xr-x 2 root root 4.0K Sep 20 19:46 pvc-d55626b9-9e3b-11e7-a572-08002772c173/

[yuvipanda]

Am convinced now this is because the process runs by default with umask 022, and so 0777 gets set as 0755 instead.

We could drop umask to 0000 just before this call and then restore it afterwards

[dlorenc]

What about doing something like this:
https://github.com/kubernetes/kubernetes/blob/9e223539290b5401a3b912ea429147a01c3fda75/pkg/volume/util/atomic_writer.go#L360

where we'd set the permissions via a call to chmod after creation, rather than setting/resetting the process-level umask?

[dlorenc]

Thanks for figuring this out, by the way!

[yuvipanda]

That works too, and might be better than fiddling with umask (since umask is process wide afaik)! I'll amend the patch later today.

[yuvipanda]

@dlorenc np, and thanks for reviewing the PR so quickly!

[antoineco]

This was supposed to fix the fsGroup compatibility, but doesn't seem to.

minikube v0.24.1

With the following securityContext

      securityContext:
        fsGroup: 20003

and the following PVC template

  volumeClaimTemplates:
  - metadata:
      name: datadir
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 5Gi

the host directories are still created with the following mode
drwxr-xr-x 2 root root 4096 Dec 1 16:47 /tmp/hostpath-provisioner/pvc-541614b7-d6b7-11e7-a722-36d29dc40439

[sonnysideup]

I'm seeing the same issue running minikube version: v0.24.1. I'm dynamically creating a couple of PVCs/PVs when launching a StatefulSet. This, in turn, is using the default storage provisioner (k8s.io/minikube-hostpath).