Issue

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

Release Notes

.`systemd` now correctly manages the `/run/user/0` directory created by `libdnf` <br/> <br/> 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. <br/> <br/> 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`.

No. of Comments

Resolution

Done-Errata