Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Installing virt-manager and its dependencies changes '/etc/freshclam.conf' ownership to 'root:gluster' and so denies freshclam access to it. I think I installed virt-manager about 6 days ago. Not sure which exact package contains the bug. Maybe it's one of libvirt's or maybe one of gluster's. Steps to Reproduce: 1. rpm-ostree install virt-manager Actual results: '/etc/freshclam.conf' has ownership changed to 'root:gluster' and freshclam can't read it, because it's run as 'clamupdate:clamupdate'. This is what 'journalctl -u clamav-freshclam.service' showed me (irrelevant info omitted): systemd: Started ClamAV virus database updater. freshclam: ERROR: Can't open/parse the config file /etc/freshclam.conf systemd: clamav-freshclam.service: Main process exited, code=exited, status=2/INVALIDARGUMENT systemd: clamav-freshclam.service: Failed with result 'exit-code'. Expected results: '/etc/freshclam.conf' ownership stays untouched. Additional info: 'sudo chown root:clamupdate /etc/freshclam.conf' fixed the problem.
Apparently, some files in '/var/lib/clamav/' also got weird permissions: -rw-r--r--. 1 vboxadd gluster bytecode.cld -rw-r--r--. 1 clamupdate clamupdate daily.cld -rw-r--r--. 1 clamupdate virusgroup freshclam.dat -rw-r--r--. 1 clamupdate virusgroup main.cvd -rw-r--r--. 1 vboxadd gluster mirrors.dat Permissions are also wrong for: /sysroot/ostree/deploy/fedora/var/lib/clamav/bytecode.cld /sysroot/ostree/deploy/fedora/var/lib/clamav/mirrors.dat
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.
The problem still exists.
This is strange. Maybe if somehow UIDs got mixed up, so if clamupdate has uid=100, then gluster is installed, gluster user is added, but something about rpm-ostree causes ordering to be messed up and now clamupdate has uid=101 and gluster has uid=100, file ownership is going to appear to change. I would also think this would be better or different after this f42 change: https://fedoraproject.org/wiki/Changes/RPMSuportForSystemdSysusers Would be interesting to check `id -u clamupdate` before and after virt installs that trigger the issue.
I did a test on Cosmic Atomic 42 virtual machine. After `rpm-ostree install clamav clamav-freshclam`, `id -u clamupdate` returns 965. Installing `libvirt-daemon-kvm` and then `virt-manager` didn't change permissions in this test. I think it is also worth mentioning, that updating packages takes away clamupdate permissions on regular basis as well. AFAIR, there was a time when the permissions were set to something related to rdp. I think I've also seen clamav-related file/dir permissions set to UIDs/GIDs without names as well. Btw. `id -u clamupdate` returns `960` on one of my computers, while on another it returns `962`. Could all this be related to https://github.com/fedora-silverblue/issue-tracker/issues/679 ?
Good find. Yes it seems like this is some general difficulty with ostree/silverblue. The way it composes the OS is very different from traditional distros. There's a bit more info about the general problem statement here: https://gitlab.com/fedora/ostree/sig/-/issues/90 I asked in that issue where the correct place to report/track your issue is. In the mean time I'm closing this one since it is not a libvirt specific issue
Thank you and apologies for misplacing the bug report! I have learned about the dynamic UID/GID issue just a couple of days ago while looking for potential F42 -> F43 rebasing issues.
Received a reply here: https://gitlab.com/fedora/ostree/sig/-/issues/90#note_2886918483 > Right now [an issue] should be directed to the freshclam package to use either > systemd features to set ownership on directories or tmpfiles config to do > the same like: https://pagure.io/workstation-ostree-config/pull-request/706