Description of problem:
when set runAsUser/runAsGroup /fsGroup=9999 at securityContext, it takes effect. while two unexpected observation:
1. why no group id found at '/etc/groups' ? bash-5.2$ cat /etc/group | grep 9999 bash-5.2$ 2. why it's different output from below command ? bash-5.2$ id uid=9999(9999) gid=9999 groups=9999 bash-5.2$ id 9999 uid=9999(9999) gid=0(root) groups=0(root)
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
set runAsGroup explicitly and check if group id exists in /etc/group inside container. Create POD with below securitycontext securityContext: runAsUser: 64892 runAsGroup: 6263 fsGroup: 123Inside container no group id is created at /etc/group bash-5.2$ id uid=64892(64892) gid=6263 groups=6263,123 bash-5.2$ id 64892 uid=64892(64892) gid=0(root) groups=0(root) bash-5.2$ cat /etc/passwd | grep 64892 64892:x:64892:0:64892 user:/:/sbin/nologin bash-5.2$ cat /etc/group | grep 6263 bash-5.2$
Actual results:
if group id is appointed by runAsGroup, this group id should exist at /etc/group inside container.
Expected results:
Additional info:
- clones
-
OCPBUGS-41246 No id found in /etc/groups inside container [openshift-4.14.z]
- Closed
- is cloned by
-
OCPBUGS-41248 No id found in /etc/groups inside container [openshift-4.12.z]
- Closed
- links to
-
RHBA-2024:7939 OpenShift Container Platform 4.13.z bug fix update