Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-11238

libdnf may create /run/user/0 directory, causing a bad context to be applied, leading to further issues

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done-Errata
    • Icon: Major Major
    • rhel-9.4
    • rhel-9.3.0
    • libdnf
    • None
    • libdnf-0.69.0-8.el9
    • None
    • Important
    • rhel-sst-cs-software-management
    • ssg_core_services
    • 14
    • 22
    • None
    • QE ack
    • False
    • Hide

      None

      Show
      None
    • Yes
    • None
    • Bug Fix
    • Hide
      .`systemd` now correctly manages the `/run/user/0` directory created by `libdnf`

      Previously, if the `libdnf` functions were called from an Insights client before logging in root, the `/run/user/0` directory could be created with a wrong SELinux context type. This prevented `systemd` from cleaning the directory after you logged out from root.

      With this update, the `libdnf` package now sets a default creation type according to default file system labeling rules defined in a SELinux policy. As a result, `systemd` now correctly manages the `/run/user/0` directory created by `libdnf`.
      Show
      .`systemd` now correctly manages the `/run/user/0` directory created by `libdnf` Previously, if the `libdnf` functions were called from an Insights client before logging in root, the `/run/user/0` directory could be created with a wrong SELinux context type. This prevented `systemd` from cleaning the directory after you logged out from root. With this update, the `libdnf` package now sets a default creation type according to default file system labeling rules defined in a SELinux policy. As a result, `systemd` now correctly manages the `/run/user/0` directory created by `libdnf`.
    • Done
    • All
    • None

      Description of problem:

      This is observed on a customer system when insights-client executes.
      In this specific case (but there are likely other cases), the /run/user/0 directory gets created with insights_client_tmp_t context, causing systemd's user-runtime-dir@0.service unit to fail forever:

      Aug 08 13:24:22 vm-insights8 systemd[1]: Stopping User runtime directory /run/user/0...
Aug 08 13:24:22 vm-insights8 systemd-user-runtime-dir[34749]: Failed to remove runtime directory /run/user/0 (after unmounting): Permission denied
Aug 08 13:24:22 vm-insights8 systemd[1]: user-runtime-dir@0.service: Control process exited, code=exited status=1
Aug 08 13:24:22 vm-insights8 systemd[1]: user-runtime-dir@0.service: Failed with result 'exit-code'.

      The root cause for this is the libdnf code forcibly creates the /run/user/0 directory when trying to import GPG keys in ensure_socket_dir_exists() function.

      [...]

      Not creating this directory is the only reliable solution to make sure whatever the caller is, this will work.

      RHEL 9 is also affected:
      gnupg2-2.3.3-4.el9.x86_64
      libdnf-0.69.0-6.el9_3.x86_64
      librepo-1.14.5-1.el9.x86_64

              rhn-support-ppisar Petr Pisar
              rhn-support-rmetrich Renaud Métrich
              packaging-team-maint packaging-team-maint
              Eva Mrakova Eva Mrakova
              Mariya Pershina Mariya Pershina
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: