Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Previously, libvirt made control group (cgroup) requests on files that it should not have. With older kernels, such nonsensical cgroup requests were ignored; however, newer kernels are stricter, resulting in libvirt logging spurious warnings and failures to the libvirtd and audit logs. The audit log failures displayed by the ausearch tool were similar to the following:
root [date] - failed cgroup allow path rw /dev/kqemu
With this update, libvirt no longer attempts the nonsensical cgroup actions, leaving only valid attempts in the libvirtd and audit logs (making it easier to search for real cases of failure).
Description of problem:
Recent kernels are stricter about validating use of cgroups, where older kernels would silently ignore bogus data. As a result, libvirt is now spamming audit logs with failure messages, which can cause a false sense of doubt about a compromised system.
Version-Release number of selected component (if applicable):
libvirt-0.10.2-18.el6
How reproducible:
100%
Steps to Reproduce:
1. virsh start domain
2. cat /var/log/libvirt/libvirtd.log
2. auvirt --start today --all-events
3.
Actual results:
2. libvirt log includes a scary-looking:
2012-12-30 13:21:38.752+0000: 9113: warning : virCgroupMoveTask:885 : no vm cgroup in controller 3
2012-12-30 13:21:38.752+0000: 9113: warning : virCgroupMoveTask:885 : no vm cgroup in controller 4
2012-12-30 13:21:38.752+0000: 9113: warning : virCgroupMoveTask:885 : no vm cgroup in controller 6
3. audit log includes a scary-looking:
res fedora_18-32 root Wed Mar 13 18:31 - failed cgroup allow path rw /dev/kqemu
Expected results:
These results are not fatal (we intentionally don't create sub-cgroups for all controllers, and /dev/kqemu doesn't exist), so they shouldn't be logged
Additional info:
Upstream patches:
commit 7f544a4c8f0353e4ff9ca08aafbb86ff8f60da0a
Author: Daniel P. Berrange <berrange>
Date: Wed Feb 27 16:57:16 2013 +0000
Don't try to add non-existant devices to ACL
The QEMU driver has a list of devices nodes that are whitelisted
for all guests. The kernel has recently started returning an
error if you try to whitelist a device which does not exist.
This causes a warning in libvirt logs and an audit error for
1-7d50-e41ee6cd897b cgroup="/sys/fs/cgroup/devices/libvirt/qemu/vm031714/" class=path path=/dev/kqemu rdev=? acl=rw
Signed-off-by: Daniel P. Berrange <berrange>
commit 279336c5d8c44f28956b3427ab2bf207d06878e2
Author: Daniel P. Berrange <berrange>
Date: Wed Feb 27 16:51:04 2013 +0000
Avoid spamming logs with cgroups warnings
The code for putting the emulator threads in a separate cgroup
would spam the logs with warnings
2013-02-27 16:08:26.731+0000: 29624: warning : virCgroupMoveTask:887 : no vm cgroup in controller 3.731+0000: 29624: warning : virCgroupMoveTask:887 : no vm cgroup in controller 4.732+0000: 29624: warning : virCgroupMoveTask:887 : no vm cgroup in controller 6
This is because it has only created child cgroups for 3 of the
controllers, but was trying to move the processes from all the
controllers. The fix is to only try to move threads in the
controllers we actually created. Also remove the warning and
make it return a hard error to avoid such lazy callers in the
future.
Signed-off-by: Daniel P. Berrange <berrange>
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, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHBA-2013-1581.html
Description of problem: Recent kernels are stricter about validating use of cgroups, where older kernels would silently ignore bogus data. As a result, libvirt is now spamming audit logs with failure messages, which can cause a false sense of doubt about a compromised system. Version-Release number of selected component (if applicable): libvirt-0.10.2-18.el6 How reproducible: 100% Steps to Reproduce: 1. virsh start domain 2. cat /var/log/libvirt/libvirtd.log 2. auvirt --start today --all-events 3. Actual results: 2. libvirt log includes a scary-looking: 2012-12-30 13:21:38.752+0000: 9113: warning : virCgroupMoveTask:885 : no vm cgroup in controller 3 2012-12-30 13:21:38.752+0000: 9113: warning : virCgroupMoveTask:885 : no vm cgroup in controller 4 2012-12-30 13:21:38.752+0000: 9113: warning : virCgroupMoveTask:885 : no vm cgroup in controller 6 3. audit log includes a scary-looking: res fedora_18-32 root Wed Mar 13 18:31 - failed cgroup allow path rw /dev/kqemu Expected results: These results are not fatal (we intentionally don't create sub-cgroups for all controllers, and /dev/kqemu doesn't exist), so they shouldn't be logged Additional info: Upstream patches: commit 7f544a4c8f0353e4ff9ca08aafbb86ff8f60da0a Author: Daniel P. Berrange <berrange> Date: Wed Feb 27 16:57:16 2013 +0000 Don't try to add non-existant devices to ACL The QEMU driver has a list of devices nodes that are whitelisted for all guests. The kernel has recently started returning an error if you try to whitelist a device which does not exist. This causes a warning in libvirt logs and an audit error for 1-7d50-e41ee6cd897b cgroup="/sys/fs/cgroup/devices/libvirt/qemu/vm031714/" class=path path=/dev/kqemu rdev=? acl=rw Signed-off-by: Daniel P. Berrange <berrange> commit 279336c5d8c44f28956b3427ab2bf207d06878e2 Author: Daniel P. Berrange <berrange> Date: Wed Feb 27 16:51:04 2013 +0000 Avoid spamming logs with cgroups warnings The code for putting the emulator threads in a separate cgroup would spam the logs with warnings 2013-02-27 16:08:26.731+0000: 29624: warning : virCgroupMoveTask:887 : no vm cgroup in controller 3.731+0000: 29624: warning : virCgroupMoveTask:887 : no vm cgroup in controller 4.732+0000: 29624: warning : virCgroupMoveTask:887 : no vm cgroup in controller 6 This is because it has only created child cgroups for 3 of the controllers, but was trying to move the processes from all the controllers. The fix is to only try to move threads in the controllers we actually created. Also remove the warning and make it return a hard error to avoid such lazy callers in the future. Signed-off-by: Daniel P. Berrange <berrange>