Cloning the old bug since I couldn't reopen it. It looks like we changed both packages at the same time.

# rpm -qlvp setup-2.12.2-1.el8.noarch.rpm | grep lastlog
  -rw-r--r--    1 root    root                        0 Sep 10  2018 /var/log/lastlog
# rpm -qlvp setup-2.12.2-2.el8_1.1.noarch.rpm | grep lastlog
  -rw-r--r--    1 root    root                        0 Oct 30 06:09 /var/log/lastlog

# rpm -qlvp util-linux-2.32.1-8.el8.x86_64.rpm | grep lastlog
  -rw-r--r--    1 root    root                        0 Dec 11  2018 /var/log/lastlog
# rpm -qlvp util-linux-2.32.1-17.el8.x86_64.rpm | grep lastlog
  -rw-rw-r--    1 root    utmp                        0 Sep 21 05:45 /var/log/lastlog

Because setup and util-linux both monitor the same file, and they both expect it to be different, it will never pass rpm Verification. From the changes I see, it looks like the old bug was never truly resolved since setup and util-linux never matched what they though /var/log/lastlog should be

# rpm -Vf /var/log/lastlog
  .M....G..  g /var/log/lastlog

The issue was originally (bug #1699310) conflict between systemd tmpfiles setting and util-linux spec file.
Systemd uses:

 /usr/lib/tmpfiles.d/var.conf:f /var/log/lastlog 0664 root utmp-

util-linux use (since util-linux-2.32.1-10.el8):
 chown root:utmp /var/log/lastlog
 chmod 0664 /var/log/lastlog
 %ghost %attr(0664,root,utmp) %verify(not md5 size mtime) /var/log/lastlog

It seems we need to change setup.spec too. We need:

 -%ghost %attr(0644,root,root) %verify(not md5 size mtime) /var/log/lastlog
 +%ghost %attr(0664,root,utmp) %verify(not md5 size mtime) /var/log/lastlog

Reassigning to setup.

Since it can't be fixed in setup it should be fixed in util-linux and systemd.
Other option is that ownership on the file will be taken away from setup by other package.

I have no problem revert the change in util-linux spec file, but it depends on systemd where 0664,root,utmp is expected for lastlog.

*** Bug 1877271 has been marked as a duplicate of this bug. ***

Piling on to the reasons to fix this. With conflicting requrimetns between the two packages it is impossible to get the CCE-80858-4 compliance check (https://static.open-scap.org/ssg-guides/ssg-rhel8-guide-e8.html#xccdf_org.ssgproject.content_rule_rpm_verify_permissions) to pass. Which in turn means if trying to run a compliance check against system with both of these packages installed, its impossible to get the compliance checklist to fully pass without removing the rule. This is a problem if you need to for instance, pass the STIG compliance list.

*** Bug 1979406 has been marked as a duplicate of this bug. ***

As previously stated by Filip and Ian.  This is breaking CIS security compliance which is a big deal to high security customers.  We need to figure out a way to get this moving, this has been an issue for over 2 years.  

In the newest fedora 34 packages both specs are set to "root root 0100644", but systemd has changed the gid AND permissions on the actual file, so it's breaking BOTH package verifications. This should probably be fixed in upstream too.
--------------------------------------------------------------------------------------------------------------
[root@fed34 ~]# rpm -q --dump util-linux|grep lastlog
/var/log/lastlog 0 1613143278 0000000000000000000000000000000000000000000000000000000000000000 0100644 root root 0 0 0 X
[root@fed34 ~]# rpm -q ​--dump setup|grep lastlog
/var/log/lastlog 0 1611885234 0000000000000000000000000000000000000000000000000000000000000000 0100644 root root 0 0 0 X

[root@fed34 ~]# ls -l /var/log/lastlog
-rw-rw-r--. 1 root utmp 292 Jul  8 14:18 /var/log/lastlog

[root@fed34 ~]# rpm -V setup
.M....G..  g /var/log/lastlog
[root@fed34 ~]# rpm -V util-linux
.M....G..  g /var/log/lastlog
--------------------------------------------------------------------------------------------------------------

I don't understand why systemd would change the gid of a file against the rpm specs without requesting a change in the spec...  but nonetheless, they did, and we're stuck with it.

We need to:

1- remove /var/log/lastlog from the "setup" spec.
2- or change the "setup" spec, to   0100644 root utmp

*** Bug 2020235 has been marked as a duplicate of this bug. ***

https://src.fedoraproject.org/rpms/systemd/c/f97cf5817a583795592f54d9260ce5aee760fd4e?branch=rawhide

This is also a part of fix: https://src.fedoraproject.org/rpms/systemd/c/238e8e0e642296e5ef01564ea8f0d6a5f929eaf1?branch=rawhide

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 (systemd bug fix and enhancement update), 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-2022:2069

This is now an issue again, but this time in the setup package:

setup-2.12.2-6.el8.noarch       => -rw-r--r--

systemd-239-58.el8.x86_64       => -rw-rw-r--

util-linux-2.32.1-35.el8.x86_64 => -rw-rw-r--

Thanks to that, the E8 compliance is failing Verify and Correct File Permissions with RPM (CCE-80858-4)

(In reply to Lucian Maly from comment #32)
> This is now an issue again, but this time in the setup package:

Apparently the change in setup (bug 2044589) hasn't made it to 8.7.

(In reply to David Tardon from comment #33)
> (In reply to Lucian Maly from comment #32)
> > This is now an issue again, but this time in the setup package:
> 
> Apparently the change in setup (bug 2044589) hasn't made it to 8.7.

I meant 8.6, of course.