Noticed service failing after upgrading to F38: ``` Apr 29 04:25:13 x systemd[1]: Starting rpmdb-migrate.service - RPM database migration to /usr... Apr 29 04:25:13 x rpmdb_migrate[360605]: rpm: /usr/bin/rpmdb: Permission denied Apr 29 04:25:13 x systemd[1]: rpmdb-migrate.service: Main process exited, code=exited, status=1/FAILURE Apr 29 04:25:13 x systemd[1]: rpmdb-migrate.service: Failed with result 'exit-code'. Apr 29 04:25:13 x systemd[1]: Failed to start rpmdb-migrate.service - RPM database migration to /usr. ``` After a bit of investigation it looks like a selinux problem: ``` type=AVC msg=audit(1682710462.690:1046): avc: denied { getattr } for pid=361859 comm="rpmdb_migrate" path="/var/lib/rpm" dev="dm-1" ino=1740754 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=lnk_file permissive=0 type=AVC msg=audit(1682710462.695:1047): avc: denied { setgid } for pid=361861 comm="rpm" capability=6 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tclass=capability permissive=0 type=AVC msg=audit(1682710462.695:1048): avc: denied { setuid } for pid=361861 comm="rpm" capability=7 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tclass=capability permissive=0 type=AVC msg=audit(1682710462.695:1049): avc: denied { execute_no_trans } for pid=361861 comm="rpm" path="/usr/bin/rpmdb" dev="dm-1" ino=1998503 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:rpmdb_exec_t:s0 tclass=file permissive=0 ``` In order: - the script tries to check if /var/lib/rpm is a symlink, but cannot access it so the check fails even if rpmdb has already been migrated - following rpm --rebuilddb fails because rpmdb cannot be executed Probably want to give the miratedb script its own execution context, possibly just unconfined? Reproducible: Always Steps to Reproduce: 1. notice `systemctl status rpmdb-migrate.service` is failed after bot
Dominique, Was this update from a fully updated F36 or a F37 system? I haven't seen this kind of problem in any of update tests.
This is on a fully updated fedora 38, with update-testing enbled. ``` $ rpm -q selinux-policy selinux-policy-38.12-1.fc38.noarch $ rpm -qf /usr/lib/rpm/rpmdb_migrate rpm-4.18.1-3.fc38.x86_64 ``` I can still reproduce right now: ``` # /usr/lib/rpm/rpmdb_migrate rpm: /usr/bin/rpmdb: Permission denied # strace -f -Ze newfstatat /usr/lib/rpm/rpmdb_migrate ... newfstatat(AT_FDCWD, "/var/lib/rpm", 0x7ffd2ed471a0, AT_SYMLINK_NOFOLLOW) = -1 EACCES (Permission denied) ... # ls -lZd /usr/lib/rpm/rpmdb_migrate /var/lib/rpm /usr/bin/rpmdb -rwxr-xr-x. 1 root root system_u:object_r:rpmdb_exec_t:s0 20792 Apr 25 09:00 /usr/bin/rpmdb -rwxr-xr-x. 1 root root system_u:object_r:rpmdb_exec_t:s0 1027 May 3 08:17 /usr/lib/rpm/rpmdb_migrate lrwxrwxrwx. 1 root root unconfined_u:object_r:var_lib_t:s0 21 Apr 29 04:27 /var/lib/rpm -> /usr/lib/sysimage/rpm # grep AVC /var/log/audit/audit.log type=AVC msg=audit(1683069334.970:3250): avc: denied { getattr } for pid=306818 comm="rpmdb_migrate" path="/var/lib/rpm" dev="dm-1" ino=1740754 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=lnk_file permissive=0 type=AVC msg=audit(1683069334.974:3251): avc: denied { setgid } for pid=306820 comm="rpm" capability=6 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tclass=capability permissive=0 type=AVC msg=audit(1683069334.974:3252): avc: denied { setuid } for pid=306820 comm="rpm" capability=7 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tclass=capability permissive=0 type=AVC msg=audit(1683069334.974:3253): avc: denied { execute_no_trans } for pid=306820 comm="rpm" path="/usr/bin/rpmdb" dev="dm-1" ino=2382316 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:rpmdb_exec_t:s0 tclass=file permissive=0 type=AVC msg=audit(1683069363.390:3274): avc: denied { getattr } for pid=311603 comm="rpmdb_migrate" path="/var/lib/rpm" dev="dm-1" ino=1740754 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=lnk_file permissive=0 type=AVC msg=audit(1683069363.428:3275): avc: denied { setgid } for pid=311605 comm="rpm" capability=6 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tclass=capability permissive=0 type=AVC msg=audit(1683069363.428:3276): avc: denied { setuid } for pid=311605 comm="rpm" capability=7 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tclass=capability permissive=0 type=AVC msg=audit(1683069363.429:3277): avc: denied { execute_no_trans } for pid=311605 comm="rpm" path="/usr/bin/rpmdb" dev="dm-1" ino=2382316 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:rpmdb_exec_t:s0 tclass=file permissive=0 ``` (that /var/lib/rpm link type is suspicious, but restorecon doesn't try to fix it -- a directory in this place would be rpm_var_lib_t; the rule probably specifically looks for directories) I thought the service didn't fail on fedora 37 but it looks like this isn't new, my journalctl only goes back so far but I've had this error at least since March: Mar 04 05:47:14 x rpmdb_migrate[223256]: rpm: /usr/bin/rpmdb: Permission denied Thanks
The problem seems to be clear and probably can easily be fixed with # restorecon -v /var/lib/rpm I just wonder how your system is different to numerous others which were tested after rpm changed its database location, without any problem like this. Additionally, the database seems to have been already migrated, so is there any actual problem? ALso given the executable path, I suppose it should rather be used as a service only. On my system, restorecon works as expected: f38# matchpathcon /var/lib/rpm /var/lib/rpm system_u:object_r:rpm_var_lib_t:s0 f38# chcon -h -t var_lib_t /var/lib/rpm f38# ls -lZd /var/lib/rpm lrwxrwxrwx. 1 root root system_u:object_r:var_lib_t:s0 26 May 2 04:29 /var/lib/rpm -> ../../usr/lib/sysimage/rpm f38# restorecon -v /var/lib/rpm Relabeled /var/lib/rpm from system_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 f38# ls -lZd /var/lib/rpm lrwxrwxrwx. 1 root root system_u:object_r:rpm_var_lib_t:s0 26 May 2 04:29 /var/lib/rpm -> ../../usr/lib/sysimage/rpm
The problem is that the service fails, so it shows up on `systemctl list-units --failed` (and occasional monitoring I never look at) I had a second look and the service has `ConditionPathExists=/var/lib/rpm/.migratedb`, and the file does still exist, so the migration was never finished properly (to be fair to the scripts: I was already bind-mounting /var/lib/rpm from /usr before the official migration, so it failed at the rmdir step unrelated to any other rule; I'd just expect the script to work for the final cleanup) It's easy to work around for my system, I'm just reporting this for others :) Re: restorecon hmm it's weird I was sure I tried, I can confirm it restored to rpm_var_lib_t. OTOH, recreating the symlink doesn't? Which is where I come from: ``` /var/lib# rm rpm rm: remove symbolic link 'rpm'? y /var/lib# ln -s /usr/lib/sysimage/rpm rpm /var/lib# ls -lZ /var/lib/rpm lrwxrwxrwx. 1 root root unconfined_u:object_r:var_lib_t:s0 21 May 5 20:26 /var/lib/rpm -> /usr/lib/sysimage/rpm /var/lib# restorecon -v /var/lib/rpm Relabeled /var/lib/rpm from unconfined_u:object_r:var_lib_t:s0 to unconfined_u:object_r:rpm_var_lib_t:s0 ``` Also the cannot run rpmdb error is still valid, I don't see how the script would currently work. Re: running manually vs. service, I believe the transition works well, running manually runs as this: unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 root 396821 0.0 0.0 7028 3328 pts/91 S+ 20:34 0:00 /usr/bin/bash /usr/lib/rpm/rpmdb_migrate running from the service: system_u:system_r:rpmdb_t:s0 root 397131 0.0 0.0 8520 4204 ? Ss 20:35 0:00 /usr/bin/bash /usr/lib/rpm/rpmdb_migrate In either case the same permissino denied error running rpmdb shows up, regardless of the state of /var/lib/rpm.
I added a rule so that rpm-related services work, but I still don't know how did you happen to get into that state.
FEDORA-2023-a19eb5132c has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-a19eb5132c
FEDORA-2023-a19eb5132c has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-a19eb5132c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-a19eb5132c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-a19eb5132c has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.