Closed realSaltyFish closed 2 years ago
Hi.
The intention beghind g+w
is to give enough permissions for the root
group to be able to use the volume. So, if your user in your pod belongs to the root group (with arbitrary user ID, e.g. 1234:0
) then the volume should ™️ be writable.
This is how volume permissions also work for example in OpenShift: The user ID in any pod is completely arbitrary, yet the user always belongs to root
group.
I thought about adding some ownership feature before. But the problem is, that this provisioner is not a full-blown CSI driver where the volume permissions automatically get adjusted to whatever user ID the mounting pod is running on. This provisioner just does initial volume creation, after creation it's left untouched. So if your pod is requiring user ID 1234
in one version, but 33
in another, the provisioner can't change it for you (assuming the provisoner knows which user ID in the first place, this isn't in the PVC spec).
Did you consider an alternative approach, e.g. an init container that runs as root user but changes permissions for the app container to the correct user ID?
Hi @RealSaltyFish . Is your question answered?
This makes sense to me. Thanks!
Thanks for this awesome software! It fits perfectly in a niche position in my project. As I can see currently
update-permissions.sh
runschmod g+w
to newly created datasets. However, these dataset mountpoints are still owned byroot:root
, thus an ordinary user in k8s pods will not be able to write there. Can you explain what the point is aboutg+w
? Can we change it too+w
or do a chown to a specific user instead?