Decision about volume permission change

[gnufied]

In Kubernetes at least - before a volume is exposed inside a pod, the CO will recursively change permission of volumes to match uid/gid as which pod is running. But this does happen for all volume types. For example - NFS, GlusterFS. For most block storage volume types, it is necessary to change volume permissions before being exposed inside a pod. It may be necessary to change permissions for some ephemeral volume types but not always.

So far we have used some rough heuristics such as fsType etc to determine the fact that, if CO needs to change permissions but I think it is not perfect. It should be upto the volume plugin to specify and control this behaviour and hence I am thinking of moving this to CSI spec.

I haven't yet thought a particular RPC call that should contain this information but I think we can figure that out later, if we agree to have this in CSI spec.

cc @saad-ali @msau42

[jieyu]

@gnufied can you articulate why volume plugin is responsible for volume permission change, as compared to CO doing it in a generic way (supplementary gid, or posix ACLs)?

[gnufied]

We discussed this today in CSI call. We are going to try and handle this in Kubernetes for now. I am going to close it. We can reopen it later, should it become a pressing issue.

[seh]

This subject came up again in the "csi" channel in the "Kubernetes" Slack team.