Bug 2191724
Summary: | rpmdb_migrate selinux policy making service fail | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dominique Martinet <g.fhnrunznrqeqf> |
Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 38 | CC: | dwalsh, lvrabec, mmalik, nknazeko, omosnacek, pkoncity, vmojzis, zpytela |
Target Milestone: | --- | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | selinux-policy-38.15-1.fc38 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2023-05-31 17:32:18 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dominique Martinet
2023-04-28 22:17:27 UTC
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. |