Bug 1699310

Summary: rpm -V setup fail on /var/log/lastlog
Product: Red Hat Enterprise Linux 8 Reporter: David Jež <djez>
Component: util-linuxAssignee: Karel Zak <kzak>
Status: CLOSED ERRATA QA Contact: Radka Brychtova <rskvaril>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.0CC: jcastran, kzak, systemd-maint
Target Milestone: rc   
Target Release: 8.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: util-linux-2.32.1-10.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1798685 (view as bug list) Environment:
Last Closed: 2019-11-05 22:26:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1798685, 2000477, 2044984    

Description David Jež 2019-04-12 11:50:13 UTC
Description of problem:
File /var/log/lastlog has set root.root 644 permissions in rpm but it is root.utmp 664 on filesystem.

Version-Release number of selected component (if applicable):
setup-2.12.2-1.el8

How reproducible:
Always

Steps to Reproduce:
1. rpm -V setup

Actual results:
.M....G..  g /var/log/lastlog

Expected results:
No error

Additional info:
See for example http://beaker-archive.host.prod.eng.bos.redhat.com/beaker-logs/2019/03/34027/3402722/6601776/89286045/taskout.log

Comment 1 Ondrej Vasik 2019-04-18 08:55:00 UTC
Adding Karel to cc, as lastlog is from util-linux package . Setup package just owns /var/log/lastlog - probably for historic reasons. It doesn't even create the file, so any package which creates the file is actually responsible for the unclean rpm -V output.
Karel, any suspects? (For me either shadow-utils or systemd).

Comment 2 Karel Zak 2019-04-18 09:44:43 UTC
We have in util-linux.spec file:

%post           
# only for minimal buildroots without /var/log
[ -d /var/log ] || mkdir -p /var/log
touch /var/log/lastlog
chown root:root /var/log/lastlog
chmod 0644 /var/log/lastlog
# Fix the file context, do not use restorecon
if [ -x /usr/sbin/selinuxenabled ] && /usr/sbin/selinuxenabled; then
        SECXT=$( /usr/sbin/matchpathcon -n /var/log/lastlog 2> /dev/null )
        if [ -n "$SECXT" ]; then
                # Selinux enabled, but without policy? It's true for buildroots
                # without selinux stuff on host machine with enabled selinux.
                # We don't want to use any RPM dependence on selinux policy for
                # matchpathcon(2). SELinux policy should be optional.
                /usr/bin/chcon "$SECXT"  /var/log/lastlog >/dev/null 2>&1 || :
        fi      
fi 

%files
%ghost %attr(0644,root,root) %verify(not md5 size mtime) /var/log/lastlog

The question is where "root.utmp" comes from. login(1) is able to create the file 
on the fly, but it does not explain "utmp" group.

Anyway, would be better move the file from setup to util-linux?

Comment 3 Karel Zak 2019-04-18 09:46:45 UTC
Ah, I see it:

$ git grep lastlog
...
tmpfiles.d/var.conf.m4:f /var/log/lastlog 0664 root utmp -


... systemd upstream tree :-)

Comment 4 Karel Zak 2019-04-18 09:49:06 UTC
It seems we need to sync
   /usr/lib/tmpfiles.d/var.conf:f /var/log/lastlog 0664 root utmp -

with util-linux spec file.

Comment 5 Karel Zak 2019-04-18 09:51:43 UTC
CC: systemd guys. Any suggestion -- why we need "root.utmp" for lastlog?

Comment 6 Lukáš Nykrýn 2019-04-18 10:57:41 UTC
It seems to be a custom on other distributions that utmp group can write to these files. See https://github.com/systemd/systemd/issues/6994

Comment 13 errata-xmlrpc 2019-11-05 22:26:57 UTC
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:3603