Description of problem: When we create a file using a MachineConfig resource and we define a user, the user is ignored. Version-Release number of MCO (Machine Config Operator) (if applicable): $ oc get co machine-config NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE machine-config 4.10.0-0.nightly-2021-11-25-064515 True False False 65m Platform (AWS, VSphere, Metal, etc.): AWS Are you certain that the root cause of the issue being reported is the MCO (Machine Config Operator)? (Y/N/Not sure): Yes How reproducible: Always Did you catch this issue by running a Jenkins job? If yes, please list: 1. Jenkins job: 2. Profile: Steps to Reproduce: 1. Create this MachineConfig apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: z99-core-test spec: config: ignition: version: 3.2.0 storage: files: - contents: source: data:;base64,H4sIAAAAAAAA/zSRQc6bIQxE998p5gBRTtEuKnXRTQ/gwiSxBDYB+1N6+4om/w4J6THv8dMnO3Ss7KjefGJpQDrjguK2WIKRE1J16Cpqd7BpXLBYUf2g5upeEezDJ9SKVq1pgQw0+eOTYLzRRJe7CaTpM+UK/I6Dph1S0XUfTppKv+CZumC+YmYFX5xFQ0LdkK1JL/5G6zpMl+6n/jN1gC9QULx3r/42eKbEFfi2mZJB6MzJj63aMTkmH7TKqQE1nN5yhARxbldwLaJoa1+NCCZueVeJw/YiDJkqkfMKfH8VjmDukhbwUoRFAiWHVgkJmBvGdK20uBxrx1JDyTZkm8NvNy0qqFyc+7Z72ztkJ9IKrk/a7NfjOH61XODJ+Tce+39+4CEnIbWy/gMAAP//AQAA//8Kgosz3wEAAA== path: /etc/test-file-core-user user: name: core - contents: source: data:;base64,H4sIAAAAAAAA/zSRQc6bIQxE998p5gBRTtEuKnXRTQ/gwiSxBDYB+1N6+4om/w4J6THv8dMnO3Ss7KjefGJpQDrjguK2WIKRE1J16Cpqd7BpXLBYUf2g5upeEezDJ9SKVq1pgQw0+eOTYLzRRJe7CaTpM+UK/I6Dph1S0XUfTppKv+CZumC+YmYFX5xFQ0LdkK1JL/5G6zpMl+6n/jN1gC9QULx3r/42eKbEFfi2mZJB6MzJj63aMTkmH7TKqQE1nN5yhARxbldwLaJoa1+NCCZueVeJw/YiDJkqkfMKfH8VjmDukhbwUoRFAiWHVgkJmBvGdK20uBxrx1JDyTZkm8NvNy0qqFyc+7Z72ztkJ9IKrk/a7NfjOH61XODJ+Tce+39+4CEnIbWy/gMAAP//AQAA//8Kgosz3wEAAA== path: /home/core/test-file-core-user user: name: core 2. Wait until the MCP has finished the configuration Actual results: The owner of the files is "root", and not the "core" user as defined in the configuration. $ oc debug node/ip-10-0-55-255.us-east-2.compute.internal Starting pod/ip-10-0-55-255us-east-2computeinternal-debug ... To use host binaries, run `chroot /host` Pod IP: 10.0.55.255 If you don't see a command prompt, try pressing enter. sh-4.4# chroot /host sh-4.4# ls -larth /home/core/test-file-core-user -rw-r--r--. 1 root root 316 Nov 26 19:43 /home/core/test-file-core-user sh-4.4# id core uid=1001(core) gid=1002(core) groups=1002(core) Expected results: The owner of the files should be the user defined in the config, "core". Additional info:
I confirm this behavior on 4.10 nightlies on RHCOS nodes. This is weird as by looking at MCO code for writing files does consider user name. This looks like a bug to me. @Sergio did you notice this behavior in 4.10 or earlier version as well?
Marking not a blocker due to this being not a regression
Verified using IPI on AWS version: $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.13.0-0.nightly-2023-02-09-032930 True False 97m Cluster version is 4.13.0-0.nightly-2023-02-09-032930 Steps: 1. Create a MC deploying several files with different users: apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: test-machine-config-users spec: config: ignition: version: 3.1.0 storage: files: - contents: source: data:text/plain;charset=utf-8;base64,dGVzdA== verification: {} mode: 420 #0644 path: /etc/core-name-test-file.test user: name: core - contents: source: data:text/plain;charset=utf-8;base64,dGVzdA== verification: {} mode: 416 #0640 path: /etc/core-id-test-file.test user: id: 1000 - contents: source: data:text/plain;charset=utf-8;base64,dGVzdA== verification: {} mode: 384 #0600 path: /etc/root-id-test-file.test user: id: 0 2. Wait for MCP to be updated 3. Check that the values are the right ones ]$ oc debug node/ip-10-0-141-152.us-east-2.compute.internal -- chroot /host ls -larth /etc |grep "test-file" Starting pod/ip-10-0-141-152us-east-2computeinternal-debug ... To use host binaries, run `chroot /host` Removing debug pod ... -rw-r--r--. 1 core root 4 Feb 9 10:21 core-name-test-file.test -rw-r-----. 1 core root 4 Feb 9 10:21 core-id-test-file.test -rw-------. 1 root root 4 Feb 9 10:21 root-id-test-file.test [fedora@preserve-sregidor-work openshift-tests-private]$ oc debug node/ip-10-0-141-152.us-east-2.compute.internal -- chroot /host cat /etc/core-name-test-file.test /etc/core-id-test-file.test /etc/root-id-test-file.test Starting pod/ip-10-0-141-152us-east-2computeinternal-debug ... To use host binaries, run `chroot /host` testtesttest Removing debug pod ... 4. Create a MC with a wrong user apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: test-machine-config-wrong spec: config: ignition: version: 3.1.0 storage: files: - contents: source: data:text/plain;charset=utf-8;base64,dGVzdA== verification: {} filesystem: root mode: 420 path: /etc/nouser-test-file.test user: name: coret 5. MCP is degraded reporting this error: - lastTransitionTime: "2023-02-09T10:07:18Z" message: 'Node ip-10-0-141-152.us-east-2.compute.internal is reporting: "failed to retrieve file ownership for file \"/etc/nouser-test-file.test\": failed to retrieve UserID for username: coret"' reason: 1 nodes are reporting degraded status on sync status: "True" type: NodeDegraded 6. Remove the wrong MC, fix the node and create new MC with a non-existent user id: apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: test-machine-config-wrong-id spec: config: ignition: version: 3.1.0 storage: files: - contents: source: data:text/plain;charset=utf-8;base64,dGVzdA== verification: {} filesystem: root mode: 420 #0644 path: /etc/nouser-test-file.test user: id: 12343 7. Wait for MCP to be updated 8. A file was created with this ID -rw-r--r--. 1 12343 root 4 Feb 9 11:00 nouser-id-test-file.test We move the status to VERFIED.
There is an error in the "test-machine-config-wrong-id" MC in my previous comment. Obviously the path that I used was " path: /etc/nouser-test-id-file.test" and not "path: /etc/nouser-test-file.test".
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: OpenShift Container Platform 4.13.0 security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2023:1326