Bug 2027000 - The user is ignored when we create a new file using a MachineConfig
Summary: The user is ignored when we create a new file using a MachineConfig
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Machine Config Operator
Version: 4.10
Hardware: Unspecified
OS: Unspecified
low
high
Target Milestone: ---
: 4.13.0
Assignee: David Joshy
QA Contact: Sergio
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-11-26 20:12 UTC by Sergio
Modified: 2023-05-17 22:46 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-05-17 22:46:32 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift machine-config-operator pull 3541 0 None open Bug 2027000: The user is ignored when we create a new file using a MachineConfig 2023-02-07 16:10:30 UTC
Red Hat Product Errata RHSA-2023:1326 0 None None None 2023-05-17 22:46:44 UTC

Description Sergio 2021-11-26 20:12:42 UTC
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:

Comment 1 Sinny Kumari 2021-11-29 10:23:15 UTC
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?

Comment 2 Yu Qi Zhang 2021-12-15 19:21:34 UTC
Marking not a blocker due to this being not a regression

Comment 7 Sergio 2023-02-09 11:13:52 UTC
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.

Comment 8 Sergio 2023-02-09 11:16:08 UTC
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".

Comment 11 errata-xmlrpc 2023-05-17 22:46:32 UTC
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


Note You need to log in before you can comment on or make changes to this bug.