Description of problem: File permissions from the rpm do not match the runtime permissions on several files. This results in mode failures on rpm -Va. Most noticed on systems in which DISA STIG is being performed and file permissions should not be less than the rpm provides or it is considered a finding during an audit. Important for government users and contractors who will be performing DISA STIG. Version-Release number of selected component (if applicable): libvirt-lock-sanlock-4.5.0-10.el7_6.6.x86_64 How reproducible: Always Steps to Reproduce: 1. # yum install libvirt-lock-sanlock 2. # rpm -V libvirt-lock-sanlock (or scan with openscap using DISA STIG, which will perform an rpm -Va) Actual results: The following files have permissions that are more permissive than the rpm provides: /var/lib/libvirt/sanlock Expected results: The file permissions provided via rpm should match the final runtime permissions (or they should be less restrictive on the rpm than the runtime permissions, which would not result in a finding). Additional info: The following output shows what it "should be" according to the rpm, as well as what it "actually is" after the package has been installed. This could be resolved by using the proper permissions in the spec file, so that rpm -Va will not flag on these files, or the actual source files could have permissions changed to match what they are after installation. From rpm: libvirt-lock-sanlock-4.5.0-10.el7_6.6.x86_64 /var/lib/libvirt/sanlock SHOULD BE: 700 ACTUALLY IS: 770 --------------------------- Looks like the relevant portion from the libvirt spec file is the following: 1897 %if %{with_sanlock} 1898 %post lock-sanlock 1899 if getent group sanlock > /dev/null ; then 1900 chmod 0770 %{_localstatedir}/lib/libvirt/sanlock 1901 chown root:sanlock %{_localstatedir}/lib/libvirt/sanlock 1902 fi 1903 %endif While on line 2177 it states that the permissions should be 0700. This means that out of the box the libvirt-lock-sanlock package will fail rpm verification, and will be a finding for anyone attempting to do audits, since the permissions are more permissive than the rpm states they should be. 2177 %dir %attr(0700, root, root) %{_localstatedir}/lib/libvirt/sanlock
It is a known behavior. I'm not sure if it is a bug. As we QE have confirmed with developers that it is by design. In the post install script Dev try to change the directory to be accessible for sanlock group if that is present in the system. Let's double confirm with developers.
That's correct. On the other hand, the directory is created by libvirt-lock-sanlock subpackage, which depends on sanlock. So if the sanlock group is actually created by the sanlock package (I'll check this), we should be able to set the owner and permissions unconditionally.
Patch sent upstream for review: https://www.redhat.com/archives/libvir-list/2019-May/msg00593.html
This will be addressed in the next major release.
Fixed upstream by commit e67b0a45769bfdca48520193e9ad1209b900d64f Refs: v5.3.0-146-ge67b0a4576 Author: Jiri Denemark <jdenemar> AuthorDate: Tue May 21 13:09:22 2019 +0200 Commit: Jiri Denemark <jdenemar> CommitDate: Mon May 27 15:00:11 2019 +0200 spec: Unconditionally set ownership of /var/lib/libvirt/sanlock The libvirt-lock-sanlock subpackage requires sanlock to be installed first and the sanlock package creates the sanlock group on all distros we care about in the spec file (Fedora and RHEL >= 7). Thus instead of setting the ownership and permissions in a post scriptlet only when the sanlock group exists we can just install the directory with the appropriate metadata. https://bugzilla.redhat.com/show_bug.cgi?id=1702758 Signed-off-by: Jiri Denemark <jdenemar> Acked-by: Michal Privoznik <mprivozn>
Reproduce the bug on # rpm -q libvirt-lock-sanlock libvirt-lock-sanlock-5.0.0-8.module+el8.0.1+3222+2dc794c6.x86_64 # rpm -V libvirt-lock-sanlock .M....G.. /var/lib/libvirt/sanlock verify on libvirt-lock-sanlock--5.4.0-2 # rpm -q libvirt-lock-sanlock libvirt-lock-sanlock-5.4.0-2.module+el8.1.0+3523+b348b848.x86_64 # rpm -V libvirt-lock-sanlock ==> no outputs # echo $? 0 # systemctl stop libvirtd # rpm -V libvirt-lock-sanlock ==> no outputs
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. https://access.redhat.com/errata/RHBA-2019:3723