kubernetes: Volume ownership function ignore errors during chown or chmod

What happened: In current SetVolumeOwnership function, it ignore any errors returned from chmod or chown. This means that even if ownership or permission is not set up correctly, pods will still be starting and it might cause some unexpected behavior.

Also noticed that in configmap_test.go, the test sets the fsGroup for the volume. However, seems like bazel test are running under non-root, so chown to an non existing group will have error “permission denied” and fail to set up fsGroup. But the test does not check this ownership, it still pass.

What you expected to happen: SetVolumeOnwerhsip should fail if chown/chmod fails. Also the configmap test may not set fsGroup if we cannot guarantee the test is running under root. We can have a separate test for this SetVolumeOwnership function to find out existing group id from current user and use that group to set up.

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

Anything else we need to know?:

Environment:

  • Kubernetes version (use kubectl version):
  • Cloud provider or hardware configuration:
  • OS (e.g: cat /etc/os-release):
  • Kernel (e.g. uname -a):
  • Install tools:
  • Network plugin and version (if this is a network-related bug):
  • Others:

About this issue

  • Original URL
  • State: open
  • Created 5 years ago
  • Comments: 20 (11 by maintainers)

Most upvoted comments

We found this issue occurs many time in my environment. We’re using kubernetes 1.14.3.

securityContext: fsGroup: 1771 runAsGroup: 1771 runAsUser: 1771 supplementalGroups: - 1

drwxrwsr-x. 5 root root 4096 Nov 14 07:04 pvc-c8b2920e-06ac-11ea-b7a0-00fd45f67d60

Pls take effort on this issue and open the ticket.