Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-44667

Files inside the pod are being created with root ownership after an OpenShift cluster restart, despite using non-root user configuration, and the issue is related to how the container runtime or kubelet handles emptyDir data differently on restart.

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • 4.14
    • Node / Kubelet
    • None
    • Important
    • None
    • False
    • Hide

      None

      Show
      None

      Description of problem:

          After an OpenShift cluster restart, files within a pod are being created with root ownership, despite the pod's containers being configured to run as a non-root user (runAsUser: 1000710000). The issue only occurs when reusing emptyDir data from a previous pod run, and the file ownership issue does not appear during the initial pod start. The behavior suggests that the container runtime or kubelet handles emptyDir volumes differently after a cluster restart, potentially causing incorrect file ownership when the emptyDir data is remounted.The problem occurs in pods with identical security contexts for the init and main containers, both configured to run as a non-root user, yet files in the emptyDir volumes are mistakenly assigned root ownership upon pod restart. The issue appears to be related to the persistence of stale emptyDir data and does not manifest when the --delete-emptydir-data flag is used during cluster shutdown, as seen in OpenShift 4.16. This flag clears stale data, preventing the problem from occurring.

      Version-Release number of selected component (if applicable):

          4.14

      How reproducible:

          The issue is consistently reproducible after an OpenShift cluster restart, when emptyDir volumes are reused and remounted. The file ownership issue does not occur on the initial pod start, but only after the cluster restart.

      Steps to Reproduce:

          1. Create a pod with an init container and a main container, both configured to run as a non-root user (runAsUser: 1000710000).
           2.Mount an emptyDir volume in both containers, with the init container creating a file in the volume.
           3.On the initial pod start, verify the file ownership inside the container and the mounted PVC, ensuring that the files are owned by the non-root user.
      4. Restart the OpenShift cluster, preserving the emptyDir volumes.
      5. After the cluster restart, inspect the pod's file ownership again, particularly inside the emptyDir volume. You should observe that the files are now owned by root, despite the non-root configuration in the pod's security context.     

      Actual results:

          After an OpenShift cluster restart, files in the emptyDir volumes are created with root ownership (root:root), even though both the init container and the main container are configured to run as a non-root user (runAsUser: 1000710000). This issue occurs only after the cluster restart, when the emptyDir data is reused and remounted.

      Expected results:

          the files inside the emptyDir volume should retain the ownership of the non-root user (runAsUser: 1000710000) after a cluster restart, as per the pod's security context configuration. There should be no ownership change to root, as the containers are configured to run as non-root users.

      Additional info:

          The issue is only reproducible after a cluster restart when the emptyDir data is persisted.
      The issue does not occur on the initial pod start.
      The behavior differs when the --delete-emptydir-data flag is used during cluster shutdown in OpenShift 4.16, which clears stale emptyDir data and prevents the ownership issue.
      The problem could be related to how the container runtime or kubelet handles emptyDir volumes during a cluster restart.4o mini

              aos-node@redhat.com Node Team Bot Account
              rhn-support-vismishr Vishvranjan Mishra
              Sunil Choudhary Sunil Choudhary
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated: