Last night, cockpit's TestAccounts.testUserPasswords started failing [1] in rawhide. In particular, logins via cockpit-session are not added to /var/lib/lastlog/lastlog2.db any more. The journal[2] shows it's due to SELinux: Jul 22 18:47:27 ip-172-31-31-34.us-east-2.compute.internal cockpit-session[202642]: pam_unix(cockpit:session): session opened for user admin(uid=1001) by admin(uid=0) Jul 22 18:47:27 ip-172-31-31-34.us-east-2.compute.internal cockpit-session[202642]: pam_lastlog2(cockpit:session): Cannot create/open database (/var/lib/lastlog/lastlog2.db): unable to open database file Jul 22 18:47:27 ip-172-31-31-34.us-east-2.compute.internal audit[202642]: AVC avc: denied { create } for pid=202642 comm="cockpit-session" name="lastlog2.db" scontext=system_u:system_r:cockpit_session_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 I can easily reproduce this with taking our current Fedora rawhide VM image (which is offline/static, and where the test passes), and upgrading *only* shadow-utils from 2:4.17.4-1.fc43 to 2:4.18.0-1.fc43. In particular, there is also an selinux-policy 41.45-1.fc43 → 42.2-1.fc43 update available, but installing that also (or just all 145 available updates, yay rebuild time) and rebooting does not change anything, it's still broken. The ownership/context of lastlog2.db didn't change, both on the old and new VM it is "system_u:object_r:var_lib_t:s0". Cockpit's SELinux policy has [3] auth_write_login_records(cockpit_session_t) which should be the correct abstraction for lastlog2. But somehow this broke now. I can't say if that's an actual regression in shadow-utils, or an intended behaviour change where selinux-policy has to follow suit. If it's the latter, please reassign to selinux-policy. This isn't actually Cockpit specific: Logging into the VM with ssh as some user (I tried "admin") fails the same way: sshd-session[1294]: pam_unix(sshd:session): session opened for user admin(uid=1000) by admin(uid=0) audit[1294]: AVC avc: denied { getattr } for pid=1294 comm="sshd-session" path="/var/lib/lastlog/lastlog2.db" dev="vda4" ino=28818 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=0 sshd-session[1294]: pam_lastlog2(sshd:session): Cannot create/open database (/var/lib/lastlog/lastlog2.db): unable to open database file [1] https://artifacts.dev.testing-farm.io/d4f17433-c0de-4500-a514-91c5e21a44c7/work-mainyyyoftjl/plans/all/main/execute/data/guest/default-0/test/browser/main-1/output.txt [2] https://artifacts.dev.testing-farm.io/d4f17433-c0de-4500-a514-91c5e21a44c7/work-mainyyyoftjl/plans/all/main/execute/data/guest/default-0/test/browser/main-1/data/TestAccounts-testUserPasswords-fedora-43-10.88.0.1-22-FAIL.log.gz [3] https://github.com/cockpit-project/cockpit/blob/ceb01e2f84912874b7cdc700f523c0eafb0da664/selinux/cockpit.te#L186C1-L187C1 Reproducible: Always Steps to Reproduce: 1. Log into the VM with SSH or Cockpit 2. Observe that `lastlog2` entries are not updated 3. Check journal for SELinux rejections.
Hello Martin, We recently migrated from lastlog (provided by shadow) to lastlog2 (provided by util-linux) (see https://bugzilla.redhat.com/show_bug.cgi?id=2360108) and it is possible that this is the change that caused this problem. In fact, I doubt very much that upgrading shadow-utils to version 4.18.0 is the root cause, as this version has nothing to do with lastlog2. In any case, this looks more like a problem with SELinux tagging, so I'm assigning it to that team. CC'ing @kzak
Right, as I said it might not be the root cause, but it is the trigger. Thanks for reassigning!
So it looks this change got to Fedora completely untested, neither clean install nor upgrade works - database is not migrated and lastlog2 does not display logins. The change introduced a new directory, new service, and new behaviour of some commands or libraries, all of which usually require being backed by appropriate SELinux policy changes. https://fedoraproject.org/wiki/Changes/Migrate_to_lastlog2 It would be helpful if the directory was in util-linux rpm.
Speaking of migration to lastlog2, SELinux denials listed in the following bug (and its duplicates) now finally make sense: * https://bugzilla.redhat.com/show_bug.cgi?id=2379871
*** Bug 2383215 has been marked as a duplicate of this bug. ***
*** Bug 2382115 has been marked as a duplicate of this bug. ***
*** Bug 2383682 has been marked as a duplicate of this bug. ***
Please include /var/lib/lastlog/ in liblastlog2 rpm files list. It will be created by the first login process otherwise, but having it in the rpm is safer to take care of permissions, and anyway directory on a filesystem should rather have a package which owns it.
(In reply to Zdenek Pytela from comment #8) > Please include /var/lib/lastlog/ in liblastlog2 rpm files list. Fixed: - commit https://src.fedoraproject.org/rpms/util-linux/c/39c148ff89d0a3239125c1cd5da72b47dc1e7e4f?branch=rawhide - built util-linux-2.41.1-15.fc43 (https://koji.fedoraproject.org/koji/taskinfo?taskID=135722444) Thanks, guys!
Confirmed fixed by the Cockpit CI: https://github.com/cockpit-project/bots/pull/8121 We didn't see this fail in the last 24 days. Thanks!