Bug 1461313
| Summary: | Rebuilding of rpm db set wrong SELinux context | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Lukas Slebodnik <lslebodn> | ||||
| Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 32 | CC: | 7d28c752, al.dunsmuir, arya.senna, awilliam, bcotton, bitlord0xff, bugzilla, bztdlinux, capl, cberlinger, Claude.Frantz, collura, daniel, david.abdurachmanov, dhcpme, dkaylor, dmick, dwalsh, ed.greshko, ego.cordatus, egor.artemov, fedora, ffesti, fukidid, gregory.lee.bartholomew, heldwin, hornaman, htl10, ignatenko, jan.vesely, kardos.lubos, kmansoft, knst.kolinko, Krause.Markus, kvolny, lvrabec, mattdm, mattia.verga, mdaenzer, mgrepl, mhroncok, mh, michael, mikael.bjarmkvist, mikhail.v.gavrilov, mtessun, ncoghlan, ndbecker2, nixuser, nmg921, noloader, nospam, omichael, packaging-team-maint, plautrba, pmatilai, pmoore, ppywlkiqletw, prarit, pwolfes, rafal.boruc, redhat-bugzilla, redhat, ryan, samuel-rhbugs, sanjay.ankur, sbauza, shawn, ssidhaye, stefan.hoelldampf, stephenbryant, thedatum+bz, the, tony, vmukhame, vondruch, wdh, wizor2, zpytela | ||||
| Target Milestone: | --- | Keywords: | Reopened, Triaged | ||||
| Target Release: | --- | Flags: | bcotton:
fedora_prioritized_bug+
|
||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | selinux-policy-3.13.1-260.20.fc26 selinux-policy-3.14.5-45.fc32 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 2166153 (view as bug list) | Environment: | |||||
| Last Closed: | 2020-11-25 01:42:21 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: | 2166153 | ||||||
| Attachments: |
|
||||||
|
Description
Lukas Slebodnik
2017-06-14 07:53:23 UTC
Workaround is quite simple. Restore context after rebuiding rpm db rpm --rebuilddb restorecon -RFv /var/lib/rpm Jun 14 10:05:38 host.example.com audit[14176]: AVC avc: denied { read } for pid=14176 comm="setroubleshootd" name="Packages" dev="dm-1" ino=8361242 scontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=0
Jun 14 10:05:38 host.example.com org.fedoraproject.Setroubleshootd[1138]: error: cannot open Packages index using db5 - Permission denied (13)
Jun 14 10:05:38 host.example.com org.fedoraproject.Setroubleshootd[1138]: error: cannot open Packages database in /var/lib/rpm
Jun 14 10:05:38 host.example.com setroubleshoot[14176]: failed to get filesystem list from rpm
Jun 14 10:05:38 host.example.com dbus-daemon[1138]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd'
Jun 14 10:05:41 host.example.com sedispatch[1104]: AVC Message for setroubleshoot, dropping message
There is a line in the selinux policy (in /etc/selinux/targeted/contexts/files/file_contexts) that should actually prevent this: /var/lib/rpmrebuilddb.*(/.*)? system_u:object_r:rpm_var_lib_t:s0 I am not quite getting why this doesn't work. As the rpmdb gets recreated in /var/lib/rpmrebuilddb.17078 on my machine which looks like it should match the RE. SELinux content is wrong, though... Lukas, Coudl you (or sb else from SELinux team) help Florian to fix it? Ok, turns out rpm used to set the SELinux context explicitly in the past. b5e3e1efee28ce0a4bb5e9eae6740d4422f75f1c removed his functionality to get rid of the SELinux dependency in the core code. So this is clearly caused by a change in rpm. I still think the policy from #3 should actually do the trick - although it doesn't. Florian, I briefly checked selinux bugs in fedora and I found 4 tickets which are caused by this bug. https://bugzilla.redhat.com/show_bug.cgi?id=1389836 https://bugzilla.redhat.com/show_bug.cgi?id=1430624 https://bugzilla.redhat.com/show_bug.cgi?id=1435992 https://bugzilla.redhat.com/show_bug.cgi?id=1436023 I would be really good to move forward this BZ. *** Bug 1435992 has been marked as a duplicate of this bug. *** Adam, Could you update your blog post? (for now) https://fedoramagazine.org/psa-errors-updating-libdb/ It seems I can't actually edit a post that's been published. I'm trying to find someone who can let me edit it now. I've now edited the blog post, and also the Common Bugs entries that mention the rebuilding the database. Adding back needinfo to LukasV @see comment4 (In reply to Florian Festi from comment #3) > There is a line in the selinux policy (in > /etc/selinux/targeted/contexts/files/file_contexts) that should actually > prevent this: > > /var/lib/rpmrebuilddb.*(/.*)? system_u:object_r:rpm_var_lib_t:s0 > > I am not quite getting why this doesn't work. As the rpmdb gets recreated in > /var/lib/rpmrebuilddb.17078 on my machine which looks like it should match > the RE. SELinux content is wrong, though... If you instead of creating /var/lib/rpmrebuilddb.$$ create the temporary directory as a subdirectory of /var/lib/rpm, then the selinux labels would be inherited from /var/lib/rpm, and the label will be correct; also after moving the file to the finale destination in /var/lib/rpm. I don't know if that is how you want to fix this issue. Created attachment 1311320 [details]
This is a suggested patch to solve the issue.
The idea is to work in a subdirectory of /var/lib/rpm, and by doing this, all selinux labels will by default be inherited from /var/lib/rpm. Assuming that the directory /var/lib/rpm is labeled correctly, then all the new database file will also be labeled correctly
(In reply to Villy Kruse from comment #13) > Created attachment 1311320 [details] > This is a suggested patch to solve the issue. > > The idea is to work in a subdirectory of /var/lib/rpm, and by doing this, > all selinux labels will by default be inherited from /var/lib/rpm. Assuming > that the directory /var/lib/rpm is labeled correctly, then all the new > database file will also be labeled correctly I am not a rpm developer. But I would like let you know that patch broke unit tests: RPM database access 59: rpm --initdb ok 60: rpm -qa ok 61: rpm -q foo ok 62: rpm -q foo- ok 63: rpm -i *.noarch.rpm ok 64: rpm -U --replacepkgs 1 ok 65: rpm -U --replacepkgs 2 expected failure (rpmdb.at:131) 66: rpm --reinstall 1 ok 67: rpm -i --relocate=.. *.i386.rpm ok 68: rpm -i --relocate=.. *.ppc64.rpm ok 69: rpmdb --rebuilddb FAILED (rpmdb.at:210) (In reply to Lukas Slebodnik from comment #14) > (In reply to Villy Kruse from comment #13) > > Created attachment 1311320 [details] > > This is a suggested patch to solve the issue. > > > > The idea is to work in a subdirectory of /var/lib/rpm, and by doing this, > > all selinux labels will by default be inherited from /var/lib/rpm. Assuming > > that the directory /var/lib/rpm is labeled correctly, then all the new > > database file will also be labeled correctly > > I am not a rpm developer. But I would like let you know that patch broke > unit tests: > RPM database access > > 59: rpm --initdb ok > 60: rpm -qa ok > 61: rpm -q foo ok > 62: rpm -q foo- ok > 63: rpm -i *.noarch.rpm ok > 64: rpm -U --replacepkgs 1 ok > 65: rpm -U --replacepkgs 2 expected failure > (rpmdb.at:131) > 66: rpm --reinstall 1 ok > 67: rpm -i --relocate=.. *.i386.rpm ok > 68: rpm -i --relocate=.. *.ppc64.rpm ok > 69: rpmdb --rebuilddb FAILED (rpmdb.at:210) I am not either. I don't get that test failure, though RPM database access 38: rpm --initdb ok 39: rpm -qa ok 40: rpm -q foo ok 41: rpm -q foo- ok 42: rpm -i *.noarch.rpm ok 43: rpm -U --replacepkgs 1 ok 44: rpm -U --replacepkgs 2 expected failure (rpmdb.at:131) 45: rpm --reinstall 1 ok 46: rpm -i --relocate=.. *.i386.rpm ok 47: rpm -i --relocate=.. *.ppc64.rpm ok 48: rpmdb --rebuilddb ok 49: rpm -U and verify status ok 50: rpm -U with _install_lang and verify status ok 51: rpm -U and verify files on disk ok 52: rpm -e and verify files removed ok Based on rpm-4.13.0.1-5.fc26.src.rpm + a patch to fix the NSS problem. commit 36db47bf59213befbb0afb37032b82e634c7ba78 Author: Panu Matilainen <pmatilai> Date: Wed May 10 09:17:20 2017 +0300 Another posible solution is to install policycoreutils-restorecond Edit /etc/selinux/restorecond.conf --- /etc/selinux/restorecond.conf +++ /etc/selinux/restorecond.conf @@ -4,5 +4,6 @@ /etc/updatedb.conf /var/run/utmp /var/log/wtmp +/var/lib/rpm/* /root/* /root/.ssh/* And run systemctl status restorecond.service (In reply to Villy Kruse from comment #15) > > RPM database access > > 38: rpm --initdb ok > 39: rpm -qa ok > 40: rpm -q foo ok > 41: rpm -q foo- ok > 42: rpm -i *.noarch.rpm ok > 43: rpm -U --replacepkgs 1 ok > 44: rpm -U --replacepkgs 2 expected failure > (rpmdb.at:131) > 45: rpm --reinstall 1 ok > 46: rpm -i --relocate=.. *.i386.rpm ok > 47: rpm -i --relocate=.. *.ppc64.rpm ok > 48: rpmdb --rebuilddb ok > 49: rpm -U and verify status ok > 50: rpm -U with _install_lang and verify status ok > 51: rpm -U and verify files on disk ok > 52: rpm -e and verify files removed ok > > Based on rpm-4.13.0.1-5.fc26.src.rpm + a patch to fix the NSS problem. > commit 36db47bf59213befbb0afb37032b82e634c7ba78 > Author: Panu Matilainen <pmatilai> > Date: Wed May 10 09:17:20 2017 +0300 It passed on f26 https://koji.fedoraproject.org/koji/taskinfo?taskID=21221554 but the same patch failed on rawhide https://koji.fedoraproject.org/koji/taskinfo?taskID=21221393 Late on party, Sorry guys. What is state of implementation in rpm right now? If is using tmpfiles with dir.XXX this is not easy from SELinux pov. Personally I prefer solution from comment#13. We're missing label for /var/lib/rpmrebuilddb.*(/.*)? this should be added to policy. But please let me know how it's working right now on F26 and Rawhide. Thanks, Lukas. (In reply to Lukas Vrabec from comment #18) > Late on party, Sorry guys. > > What is state of implementation in rpm right now? If is using tmpfiles with > dir.XXX this is not easy from SELinux pov. Personally I prefer solution from > comment#13. > > We're missing label for /var/lib/rpmrebuilddb.*(/.*)? this should be added > to policy. But please let me know how it's working right now on F26 and > Rawhide. > > Thanks, > Lukas. Solution from comment#13 does not work after this commit: Author: Florian Festi <ffesti> 2017-06-29 09:08:32 Committer: Florian Festi <ffesti> 2017-07-30 11:06:47 Parent: 98efb7f6dc222ed175516298a34e807053d125f4 (reference proper debug files whenever RemovePathPostfixes is used) Child: 4b0356c5671daafb954c8ee932742ad7da57f345 (Set permissions and owner for new database to the old values) Branches: master, remotes/origin/master, remotes/origin/rpm-4.14.x Follows: rpm-4.13.0-alpha Precedes: Replace whole rpmdb directory on rebuilddb instead of moving around files This fixes issues with rebuilding the database for another backend which before could leave behind files from the old format. ------ /var/lib/rpmrebuilddb.*(/.*)? is there already, but has no effect until you run restorecon. *** Bug 1487104 has been marked as a duplicate of this bug. *** A SELinux solution turns out to be quite simple. The problem is that when you run the rpm command the rpm and and rpmdb processes run in a unconfined_t context. If you make sure rpm runs in the rpm_t context, the rebuilt data files will have the correct SELinux labels. A cil format module fixes this problem for me: ==============8X====================== (typeattributeset cil_gen_require rpm_exec_t) (typeattributeset cil_gen_require rpm_t) (typeattributeset cil_gen_require unconfined_t) (typetransition unconfined_t rpm_exec_t process rpm_t) ==============8X====================== Tested in Fedora 26 and 27. Moving to selinux-policy: as noted above, the context is the problem. The database rebuild is always performed by /usr/bin/rpmdb executable which doesn't have an rpm-specific context. selinux-policy-3.13.1-260.20.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-1969794434 selinux-policy-3.13.1-260.20.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-1969794434 selinux-policy-3.13.1-260.20.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. Fix needed for f27 and newer. To test: 1. rpm --rebuilddb 2. ls -1Z /var/lib/rpm Expected: unconfined_u:object_r:rpm_var_lib_t:s0 Basenames unconfined_u:object_r:rpm_var_lib_t:s0 Conflictname unconfined_u:object_r:rpm_var_lib_t:s0 Dirnames unconfined_u:object_r:rpm_var_lib_t:s0 Enhancename unconfined_u:object_r:rpm_var_lib_t:s0 Filetriggername unconfined_u:object_r:rpm_var_lib_t:s0 Group unconfined_u:object_r:rpm_var_lib_t:s0 Installtid unconfined_u:object_r:rpm_var_lib_t:s0 Name unconfined_u:object_r:rpm_var_lib_t:s0 Obsoletename unconfined_u:object_r:rpm_var_lib_t:s0 Packages unconfined_u:object_r:rpm_var_lib_t:s0 Providename unconfined_u:object_r:rpm_var_lib_t:s0 Recommendname unconfined_u:object_r:rpm_var_lib_t:s0 Requirename unconfined_u:object_r:rpm_var_lib_t:s0 Sha1header unconfined_u:object_r:rpm_var_lib_t:s0 Sigmd5 unconfined_u:object_r:rpm_var_lib_t:s0 Suggestname unconfined_u:object_r:rpm_var_lib_t:s0 Supplementname unconfined_u:object_r:rpm_var_lib_t:s0 Transfiletriggername unconfined_u:object_r:rpm_var_lib_t:s0 Triggername Actual: unconfined_u:object_r:var_lib_t:s0 Basenames unconfined_u:object_r:var_lib_t:s0 Conflictname unconfined_u:object_r:var_lib_t:s0 Dirnames unconfined_u:object_r:var_lib_t:s0 Enhancename unconfined_u:object_r:var_lib_t:s0 Filetriggername unconfined_u:object_r:var_lib_t:s0 Group unconfined_u:object_r:var_lib_t:s0 Installtid unconfined_u:object_r:var_lib_t:s0 Name unconfined_u:object_r:var_lib_t:s0 Obsoletename unconfined_u:object_r:var_lib_t:s0 Packages unconfined_u:object_r:var_lib_t:s0 Providename unconfined_u:object_r:var_lib_t:s0 Recommendname unconfined_u:object_r:var_lib_t:s0 Requirename unconfined_u:object_r:var_lib_t:s0 Sha1header unconfined_u:object_r:var_lib_t:s0 Sigmd5 unconfined_u:object_r:var_lib_t:s0 Suggestname unconfined_u:object_r:var_lib_t:s0 Supplementname unconfined_u:object_r:var_lib_t:s0 Transfiletriggername unconfined_u:object_r:var_lib_t:s0 Triggername This problem is recurring in Fedora 33 rawhide. Ran restorecon -RFv /var/lib/rpm and it relabeled all the files. So rpm --rebuilddb is still getting it wrong. (In reply to Henry Kroll from comment #27) > This problem is recurring in Fedora 33 rawhide. > Ran restorecon -RFv /var/lib/rpm and it relabeled all the files. So rpm > --rebuilddb is still getting it wrong. It has been that way for the past many release. Nobody seems be affected by it. The fix outlined in comment 21 still works, though. Reopening as the fix in F26 apparently never really fixed the issue, this has been reported occasionally all along the way. *** Bug 1824265 has been marked as a duplicate of this bug. *** There seems to be plans to create rpmdb-rebuild.service in Fedora 33. Wich current SELinux policies this could fix the problem. If you run "/usr/bin/rpm --rebuilddb" as a systemd service, the SELinux labels will be created properly. However, if you instead run "/usr/bin/rpmdb --rebuilddb" as a systemd.service, the SELinux labels will not be set. That works because there is (and has been for a long time) a type transition rule for the rpm program when started from the systemd pid1 process. Villy, That sounds interesting. Still, it is a solution for F33+ and I think we should address current versions as well. The aforementioned binaries labels are different: # ls -lZ /usr/bin/rpmdb /usr/bin/rpm -rwxr-xr-x. 1 root root system_u:object_r:rpm_exec_t:s0 24864 Nov 19 10:41 /usr/bin/rpm -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 20840 Nov 19 10:41 /usr/bin/rpmdb so we can think of assigning some label other than bin_t to rpmdb as well - at which scenarios/environments rpmdb is run? Certainly it is a user session, may be a new installation, is there also some existing service running this command or any other use case? (In reply to Zdenek Pytela from comment #32) > Villy, > > That sounds interesting. Still, it is a solution for F33+ and I think we > should address current versions as well. The fix outlined in comment 21 still works, though. Current typetransitions for the rpm program (typetransition ricci_modrpm_t rpm_exec_t process rpm_t) (typetransition auditadm_sudo_t rpm_exec_t process rpm_t) (typetransition anaconda_t rpm_exec_t process rpm_t) (typetransition cloud_init_t rpm_exec_t process rpm_t) (typetransition rhnsd_t rpm_exec_t process rpm_t) (typetransition run_init_t rpm_exec_t process rpm_t) (typetransition initrc_domain rpm_exec_t process rpm_t) (typetransition system_cronjob_t rpm_exec_t process rpm_t) (typetransition crond_t rpm_exec_t process rpm_t) (typetransition system_dbusd_t rpm_exec_t process rpm_t) (typetransition initrc_domain rpm_exec_t process rpm_t) (typetransition dbadm_sudo_t rpm_exec_t process rpm_t) (typetransition sysadm_t rpm_exec_t process rpm_t) (typetransition sysadm_sudo_t rpm_exec_t process rpm_t) (typetransition staff_sudo_t rpm_exec_t process rpm_t) (typetransition osad_t rpm_exec_t process rpm_t) (typetransition pegasus_t rpm_exec_t process rpm_t) (typetransition puppetagent_t rpm_exec_t process rpm_t) (typetransition secadm_sudo_t rpm_exec_t process rpm_t) Missing is the transition from unconfined_t to rpm_t. > The aforementioned binaries labels are different: > > # ls -lZ /usr/bin/rpmdb /usr/bin/rpm > -rwxr-xr-x. 1 root root system_u:object_r:rpm_exec_t:s0 24864 Nov 19 10:41 > /usr/bin/rpm > -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 20840 Nov 19 10:41 > /usr/bin/rpmdb > > so we can think of assigning some label other than bin_t to rpmdb as well - > at which scenarios/environments rpmdb is run? You can certainly relabel /usr/bin/rpmdb to be the same as /usr/bin/rpm. When running rpm --rebuilddb it will run the rpmdb program using the same label as the rpm program itself. > Certainly it is a user session, may be a new installation, is there also some existing service > running this command or any other use case? You can find the proposed systemd unit file in the git repository https://src.fedoraproject.org/rpms/rpm.git. When running "systemctl start rpmdb-rebuild.service the program will start up as init_t, and the type transition rule will relabel it to rpm_t. Then the following rule fixes the new rpm database files. (typetransition rpm_t var_lib_t dir rpm_var_lib_t) . *** Bug 1837363 has been marked as a duplicate of this bug. *** *** Bug 1837360 has been marked as a duplicate of this bug. *** On the database rebuild, the /var/lib/rpmrebuilddb.PID directory is created first and after all work done it is renamed to /var/lib/rpm. The process runs in unconfined_t for unconfined users and in rpm_t for confined ones. Regexps cannot be used in transitions. So the easiest possible fix can consist of these steps: - label /usr/bin/rpmdb with rpm_exec_t - add fc entry for /var/lib/rpmrebuilddb.* - add unnamed filetransition for rpm_t on var_lib_t - add transition for unconfined_t on rpm_exec_t to rpm_t Other possible approaches towards resolving the problem: - add unnamed filetransition for unconfined_t on var_lib_t (this is hardly an option) - confine rpmdb in a different way (requires to write a bunch of policy rules, does not solve using the rpm command - it may be just an undocumented feature though) - label rpmdb differently only to transition to rpm_t from unconfined_t (does not solve using rpm) Note both commands can be used to deal with the database, e. g. change the backend: # rpmdb --rebuilddb --define "_db_backend sqlite" # rpm --rebuilddb --define "_db_backend sqlite" # sesearch -T -t rpm_exec_t ... type_transition auditadm_sudo_t rpm_exec_t:process rpm_t; type_transition dbadm_sudo_t rpm_exec_t:process rpm_t; type_transition init_t rpm_exec_t:process rpm_t; type_transition initrc_t rpm_exec_t:process rpm_t; type_transition secadm_sudo_t rpm_exec_t:process rpm_t; type_transition staff_sudo_t rpm_exec_t:process rpm_t; type_transition sysadm_sudo_t rpm_exec_t:process rpm_t; type_transition sysadm_t rpm_exec_t:process rpm_t; ... # sesearch -T -s rpm_t -t var_lib_t -c dir type_transition rpm_t var_lib_t:dir alsa_var_lib_t alsa; type_transition rpm_t var_lib_t:dir cert_t letsencrypt; type_transition rpm_t var_lib_t:dir ldconfig_cache_t debug; type_transition rpm_t var_lib_t:dir postgresql_db_t pgsql; type_transition rpm_t var_lib_t:dir postgresql_db_t postgres; type_transition rpm_t var_lib_t:dir postgresql_db_t postgresql; type_transition rpm_t var_lib_t:dir rpm_var_lib_t dnf; type_transition rpm_t var_lib_t:dir rpm_var_lib_t rpm; type_transition rpm_t var_lib_t:dir rpm_var_lib_t rpmrebuilddb; type_transition rpm_t var_lib_t:dir rpm_var_lib_t yum; type_transition rpm_t var_lib_t:dir rpm_var_lib_t; type_transition rpm_t var_lib_t:dir snapperd_data_t .snapshots; type_transition rpm_t var_lib_t:dir ssh_home_t .ssh; type_transition rpm_t var_lib_t:dir sssd_var_lib_t sss; type_transition rpm_t var_lib_t:dir tetex_data_t texmf; (In reply to Zdenek Pytela from comment #36) > On the database rebuild, the /var/lib/rpmrebuilddb.PID directory is created > first and after all work done it is renamed to /var/lib/rpm. The process > runs in unconfined_t for unconfined users and in rpm_t for confined ones. > Regexps cannot be used in transitions. > > So the easiest possible fix can consist of these steps: > - label /usr/bin/rpmdb with rpm_exec_t > - add fc entry for /var/lib/rpmrebuilddb.* > - add unnamed filetransition for rpm_t on var_lib_t > - add transition for unconfined_t on rpm_exec_t to rpm_t > > Other possible approaches towards resolving the problem: > - add unnamed filetransition for unconfined_t on var_lib_t (this is hardly > an option) > - confine rpmdb in a different way (requires to write a bunch of policy > rules, does not solve using the rpm command - it may be just an undocumented > feature though) > - label rpmdb differently only to transition to rpm_t from unconfined_t > (does not solve using rpm) > > Note both commands can be used to deal with the database, e. g. change the > backend: > # rpmdb --rebuilddb --define "_db_backend sqlite" > # rpm --rebuilddb --define "_db_backend sqlite" > > # sesearch -T -t rpm_exec_t > ... > type_transition auditadm_sudo_t rpm_exec_t:process rpm_t; > type_transition dbadm_sudo_t rpm_exec_t:process rpm_t; > type_transition init_t rpm_exec_t:process rpm_t; > type_transition initrc_t rpm_exec_t:process rpm_t; > type_transition secadm_sudo_t rpm_exec_t:process rpm_t; > type_transition staff_sudo_t rpm_exec_t:process rpm_t; > type_transition sysadm_sudo_t rpm_exec_t:process rpm_t; > type_transition sysadm_t rpm_exec_t:process rpm_t; > ... > > # sesearch -T -s rpm_t -t var_lib_t -c dir > type_transition rpm_t var_lib_t:dir alsa_var_lib_t alsa; > type_transition rpm_t var_lib_t:dir cert_t letsencrypt; > type_transition rpm_t var_lib_t:dir ldconfig_cache_t debug; > type_transition rpm_t var_lib_t:dir postgresql_db_t pgsql; > type_transition rpm_t var_lib_t:dir postgresql_db_t postgres; > type_transition rpm_t var_lib_t:dir postgresql_db_t postgresql; > type_transition rpm_t var_lib_t:dir rpm_var_lib_t dnf; > type_transition rpm_t var_lib_t:dir rpm_var_lib_t rpm; > type_transition rpm_t var_lib_t:dir rpm_var_lib_t rpmrebuilddb; > type_transition rpm_t var_lib_t:dir rpm_var_lib_t yum; > type_transition rpm_t var_lib_t:dir rpm_var_lib_t; > type_transition rpm_t var_lib_t:dir snapperd_data_t .snapshots; > type_transition rpm_t var_lib_t:dir ssh_home_t .ssh; > type_transition rpm_t var_lib_t:dir sssd_var_lib_t sss; > type_transition rpm_t var_lib_t:dir tetex_data_t texmf; You only needs this transition: typetransition unconfined_t rpm_exec_t:process rpm_t and the rpm process will run in a context which will do the right thing. I have this rule in my systems for many years and it works properly. If you wish you can label rpmdb the same way as rpm itself, and then add the typetransition rules the same way as for rpm. Then it would also work if you run "rpmdb --rebuilddb" instead of "rpm --rebuilddb". Running "rpm --rebuilddb" from a systemd unit will already today do the right thing, because the rpm process will then have a type transition from init_t to rpm_t. Note that rpm_exec_t for rpmdb binary is "wrong", rpm_exec_t is to grant rpm scriptlets the super powers they need. rpmdb doesn't need anything of the sort, it only needs access to the new and old rpmdb directories! 'rpmdb --rebuilddb' is the form people should really be using, and which what 'rpm --rebuilddb' will actually execute, the latter is a mere popt alias on the former. (In reply to Panu Matilainen from comment #38) > Note that rpm_exec_t for rpmdb binary is "wrong", rpm_exec_t is to grant rpm > scriptlets the super powers they need. rpmdb doesn't need anything of the > sort, it only needs access to the new and old rpmdb directories! > But, rpm is hardly ever run with those super powers. For that to happen, it needs the rule typetransition unconfined_t rpm_exec_t:process rpm_t Without that rule, the rpm process and its sup-processes will run in the unconfined_t context. Thus, the rpm_exec_t label is mostly irrelevant. What that type can do is take away the init_t or other super powers from the rpm process when started from the init_t context. > 'rpmdb --rebuilddb' is the form people should really be using, and which > what 'rpm --rebuilddb' will actually execute, the latter is a mere popt > alias on the former. It can certainly also be done that way by making a new SELinux type for rpmdb. No problem. Oh, I'm rather ignorant about the selinux details here. I just know that if programs installing rpms (rpm itself, dnf, yum etcetc) are not labeled rpm_exec_t, it'll cause rpm scriptlet failures. This was quite common thing back in the day, but my memories around this are from the early days of selinux before unconfined_t being the norm. Villy and Panu, Thank you for your views, it helped me to sort things out. I will sum it up now how I see it: There are 3 typical ways of executing the database rebuild: - user root terminal - a systemd unit - installer updating the system While "rpmdb --rebuilddb" is documented, plain rpm is not, so we can omit it for now. In order to resolve these use cases, we need to consider: 1. Add unnamed filetransition for rpm_t on var_lib_t type_transition rpm_t var_lib_t:dir rpm_var_lib_t; This is required for the directories rpmbuild.PID get the proper context. It is not sufficient for unconfined user root. 2. Label rpmdb different to bin_t This will allow a transition to confined domain. Panu, you had some concerns regarding the rpm_exec_t type for rpmdb: do you think it really is wrong? Labeling in a way to transition to rpm_t will be the easiest solution. It actually confines the process when executed from a terminal/init/cron/, may add permissions when executed from rpm_script_t, it also grants privileges which are probably not required for rpmdb. 3. Allow transition from unconfined_t to rpm_t typetransition unconfined_t rpm_exec_t:process rpm_t This can also be a part of the easy solution, just need to decide about rpm and rpmdb. Commands are usually not confined though for reason. Villy, with the rule in place, did you happen to find an example when some operation was blocked by having the rpm command confined? 4. Add unnamed filetransition for unconfined_t on var_lib_t type_transition unconfined_t var_lib_t:dir rpm_var_lib_t; I am afraid we cannot afford this. 5. Add fc entry for /var/lib/rpmrebuilddb.* This is harmless, but also only useful to support an interrupted db rebuild. Not suggesting any longer. Will think about it again and resolve it soon. (In reply to Zdenek Pytela from comment #41) > Villy and Panu, > > Thank you for your views, it helped me to sort things out. I will sum it up > now how I see it: > > There are 3 typical ways of executing the database rebuild: > - user root terminal > - a systemd unit > - installer updating the system Does any installer do that at the moment? The plan for the rpm project is to run rpmdb rebuild via a systemd unit. > > While "rpmdb --rebuilddb" is documented, plain rpm is not, so we can omit it > for now. > If you omit that, you will need to create an execution context for rpmdb as it no longer can inherit the context from rpm itself. For example make it rpmdb_exec_t for the program file and rpmdb_t for the process itself plus the type transition and type transition permission rules similar to the ones for the rpm process and program file. > In order to resolve these use cases, we need to consider: > > 1. Add unnamed filetransition for rpm_t on var_lib_t > type_transition rpm_t var_lib_t:dir rpm_var_lib_t; > This is required for the directories rpmbuild.PID get the proper context. It > is not sufficient for unconfined user root. > You already have such a rule. You may need a similar rule for the new rpmdb_t process context. > 2. Label rpmdb different to bin_t > This will allow a transition to confined domain. > Panu, you had some concerns regarding the rpm_exec_t type for rpmdb: do you > think it really is wrong? > Labeling in a way to transition to rpm_t will be the easiest solution. It > actually confines the process when executed from a terminal/init/cron/, may > add permissions when executed from rpm_script_t, it also grants privileges > which are probably not required for rpmdb. > I assume that the intention was that the rpm program and its subprograms should always run as rpm_t and not unconfined_t or any other context. > 3. Allow transition from unconfined_t to rpm_t > typetransition unconfined_t rpm_exec_t:process rpm_t > This can also be a part of the easy solution, just need to decide about rpm > and rpmdb. Commands are usually not confined though for reason. > Villy, with the rule in place, did you happen to find an example when some > operation was blocked by having the rpm command confined? > I would guess that unconfined programs would be programs which nobody have created proper SELinux rules for (yet). I have never seen any problems. The quickest way to test this without running the build process: Create a file my-rpmdb-fix.cil with this content. It is "cil" format which is a little different from the normal "te" format. ==============8X====================== (typeattributeset cil_gen_require rpm_exec_t) (typeattributeset cil_gen_require rpm_t) (typeattributeset cil_gen_require unconfined_t) (typetransition unconfined_t rpm_exec_t process rpm_t) ==============8X====================== Feed this file directly into the semodule program: semodule -i my-rpmdb-fix.cil Remove it again semodule -r my-rpmdb-fix > 4. Add unnamed filetransition for unconfined_t on var_lib_t > type_transition unconfined_t var_lib_t:dir rpm_var_lib_t; > I am afraid we cannot afford this. > I don't think that would be a good idea. Only the rpm_t or the new rpmdb_t processes should relabel new directories from var_lib_t to rpm_var_lib_t. > 5. Add fc entry for /var/lib/rpmrebuilddb.* > This is harmless, but also only useful to support an interrupted db rebuild. > Not suggesting any longer. > If you ever find such a directory and no rebuild is in progress, the best thing is to remove it and its contents. > Will think about it again and resolve it soon. (In reply to Panu Matilainen from comment #40) > Oh, I'm rather ignorant about the selinux details here. I just know that if > programs installing rpms (rpm itself, dnf, yum etcetc) are not labeled > rpm_exec_t, it'll cause rpm scriptlet failures. This was quite common thing > back in the day, but my memories around this are from the early days of > selinux before unconfined_t being the norm. That must be before my time. I started with Fedora 12 when migrating from RH9. A problem with SELinux is that apparently so few understands the details. I'm now seeing denials like this after upgrade from F31 or F32 to F33, with no manual "rpm --rebuilddb" being done at any stage. This is happening in openQA tests, e.g.: https://openqa.fedoraproject.org/tests/621346 https://openqa.fedoraproject.org/tests/621354 you can see the denials in the log files on the 'Logs & Assets' tab. Those tests just run an upgrade from a base disk image (with Fedora Server package set) using dnf system-upgrade as our official instructions recommend. (In reply to Adam Williamson from comment #44) > I'm now seeing denials like this after upgrade from F31 or F32 to F33, with > no manual "rpm --rebuilddb" being done at any stage. This is happening in > openQA tests, e.g.: > > https://openqa.fedoraproject.org/tests/621346 > https://openqa.fedoraproject.org/tests/621354 > > you can see the denials in the log files on the 'Logs & Assets' tab. Those > tests just run an upgrade from a base disk image (with Fedora Server package > set) using dnf system-upgrade as our official instructions recommend. You now have a rpmdb-rebuild.service who would run the rpmbuild process. See comment 31. The database needs to be converted from BerkeleyDB to sqlite, and rpmbuild is doing that. Excuse me for asking: Is there any progress on this issue? (In reply to Villy Kruse from comment #45) > You now have a rpmdb-rebuild.service who would run the rpmbuild process. > See comment 31. > > The database needs to be converted from BerkeleyDB to sqlite, and rpmbuild > is doing that. Not rpmbuild. That's the thing used for building packages. "rpmdb --rebuilddb" is the command used for database rebuilds (whether invoked manually or by the service) (In reply to Panu Matilainen from comment #47) > (In reply to Villy Kruse from comment #45) > > You now have a rpmdb-rebuild.service who would run the rpmbuild process. > > See comment 31. > > > > The database needs to be converted from BerkeleyDB to sqlite, and rpmbuild > > is doing that. > > Not rpmbuild. That's the thing used for building packages. > > "rpmdb --rebuilddb" is the command used for database rebuilds (whether > invoked manually or by the service) Of course you are correct. *** Bug 1881163 has been marked as a duplicate of this bug. *** After upgrading to Fedora 33, I am affected by this. I have not run `rpmdb --rebuilddb` manually, so I guess it was run by https://src.fedoraproject.org/rpms/rpm/blob/master/f/rpmdb-rebuild.service -- should that service also run `restorecon -RFv /var/lib/rpm`? (In reply to Miro Hrončok from comment #50) > After upgrading to Fedora 33, I am affected by this. I have not run `rpmdb > --rebuilddb` manually, so I guess it was run by > https://src.fedoraproject.org/rpms/rpm/blob/master/f/rpmdb-rebuild.service > -- should that service also run `restorecon -RFv /var/lib/rpm`? Yet another way to fix this. :) I expect every one who upgrades to Fedora 33 will hit this issue. The problem appears when ABRT tries to access the database. Basically bz1881163. I am proposing this a prioritized bug (the part that this happens after upgrading to Fedora 33, no the more general problem). > I expect every one who upgrades to Fedora 33 will hit this issue.
I also ran into this issue after upgrading from Fedora 32 to 33 today.
Will apply the "restorecon" workaround.
Faced this as soon as my upgrade from 32 to 33 completed and I logged in. My CPUs were sharing full 100% utilization loads back and forth and my battery was quickly draining. I ran the suggested: `rpm --rebuilddb` `restorecon -RFv /var/lib/rpm` After a minute or so my SELinux alerts soon stopped and my CPUs resolved to normal. (In reply to James Allen from comment #54) > I ran the suggested: > `rpm --rebuilddb` > `restorecon -RFv /var/lib/rpm` Rebuilding the rpmdb is *not* what is suggested here, it happens behind the scenes automatically and is what *triggers* this issue. The workaround is simply: # restorecon -RFv /var/lib/rpm Oh and FWIW, I don't believe that workaround belongs to the rpmdb-rebuild service, this is an issue created by selinux policies so the fix needs to happen there as well, rather than sprinkle restorecon's around. I agree it needs fixing in the selinux-policy package. I would not say though it was "created" by selinux policy. Is is a result of how rpm works when it rebuilds the database, and this fact has not resulted in an appropriate change in the policy yet. *** Bug 1893105 has been marked as a duplicate of this bug. *** (In reply to Zdenek Pytela from comment #56) > I agree it needs fixing in the selinux-policy package. > > I would not say though it was "created" by selinux policy. Is is a result of > how rpm works when it rebuilds the database, and this fact has not resulted > in an appropriate change in the policy yet. The way rpm is re-building the data base hasn't changed significantly since 2013. I creates a new data base in the directory /var/lib/rpmrebuilddb.$$ where '$$' is the process id. Then it either moves individual files to /var/lib/rpm or simply renames the temporary data base directory. The patch git diff 0295f4b44~..0295f4b44 diff --git a/rpm.if b/rpm.if index 79518530e..b7bd65539 100644 --- a/rpm.if +++ b/rpm.if @@ -419,6 +419,7 @@ interface(`rpm_named_filetrans',` files_var_lib_filetrans($1, rpm_var_lib_t, dir, "dnf") files_var_lib_filetrans($1, rpm_var_lib_t, dir, "yum") files_var_lib_filetrans($1, rpm_var_lib_t, dir, "rpm") + files_var_lib_filetrans($1, rpm_var_lib_t, dir, "rpmrebuilddb") ') ######################################## Could not possibly work is the new data base is not created as "rpmrebuilddb" but as "rpmrebuilddb" with a pid suffix. Thus, a file transition based on file name is not going to work. Also see bug 1167946. *** Bug 1893276 has been marked as a duplicate of this bug. *** Related and possible dups: bug 1885137, bug 1885123, bug 1893552. *** Bug 1893552 has been marked as a duplicate of this bug. *** *** Bug 1885123 has been marked as a duplicate of this bug. *** *** Bug 1885137 has been marked as a duplicate of this bug. *** *** Bug 1893552 has been marked as a duplicate of this bug. *** Same issue on two systems upgraded from F32 to F33. `restorecon -RFv /var/lib/rpm` appears to fix it. Folks, I finished the policy patches and have a copr build which seems to work as expected, i. e. rpmdb --rebuilddb creates the directory with correct type both from console and systemd service unit. The build is for rawhide only, but local build works for F33, too: https://copr.fedorainfracloud.org/coprs/zpytela/selinux-policy/build/1743918/ Lukasi, You mentioned you have unit tests. Can you use them to test the build? Here is an F33 scratchbuild: https://koji.fedoraproject.org/koji/taskinfo?taskID=54873612 PRs: https://github.com/fedora-selinux/selinux-policy/pull/471 https://github.com/fedora-selinux/selinux-policy-contrib/pull/358 Panu, in c#38 you mentioned rpmdb needs just access to the rpm database. The current policy change as proposed allows that, but not access to majority of locations, e. g. root's home directory which may be an usual place to work with files. What are other common use cases to run rpmdb? There are also switches --importdb, --exportdb, --dbpath which will work with a file in /tmp or /var/lib/rebuilddb, but not for file's in root's home. It was, on purpose, confined so that it cannot read from many locations which would affect other switches --load, --rcfile, --root. Do you think it is an issue? https://github.com/fedora-selinux/selinux-policy-contrib/pull/358#issuecomment-721684054 Additionally, rpmdb does not report an error, neither it sets exit code when read or write is not successful. # pwd /root # rpmdb --exportdb > db;echo $? 0 # ls -Zl db -rw-r--r--. 1 root root unconfined_u:object_r:admin_home_t:s0 0 Nov 4 09:43 db Accepted as a Fedora Prioritized Bug Uh, my comment was in comparison to rpm installing and erasing software, not literally "doesn't need anything". It does need to read various configuration bits spread across /etc, /usr/lib/rpm and home directory (but ~/.rpmmacros and ~/.popt are not critical for operation normally). It will not *write* anywhere besides the rpmdb path at given root, but of course ultimately both the database path and the root are both configurable and cli-overridable, and also configuration path can be diverted on the cli. As for --exportdb and --importdb, they operate on stdin/stdout, the target file is opened by the invoking shell. For some unknown reason rpmdb wants to read /etc/resolv.conf. Testing: rpmdb --rebuilddb Current version: selinux-policy-3.15.0-1.200.bz1461313.fc33.noarch selinux-policy-targeted-3.15.0-1.200.bz1461313.fc33.noarch New SELinux resports: type=AVC msg=audit(1604563886.173:322): avc: denied { getattr } for pid=14222 comm="rpmdb" path="/etc/resolv.conf" dev="sda 2" ino=19600 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:net_conf_t:s0 tclass=file pe rmissive=1 type=AVC msg=audit(1604563886.173:323): avc: denied { read } for pid=14222 comm="rpmdb" name="resolv.conf" dev="sda2" ino=1 9600 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:net_conf_t:s0 tclass=file permissive =1 type=AVC msg=audit(1604563886.173:324): avc: denied { open } for pid=14222 comm="rpmdb" path="/etc/resolv.conf" dev="sda2" ino=19600 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:net_conf_t:s0 tclass=file permi ssive=1 (In reply to Panu Matilainen from comment #70) > Uh, my comment was in comparison to rpm installing and erasing software, not > literally "doesn't need anything". I just tried to allow as low number of permissions as possible to have the rebuild working, I did not expect to "allow nothing." I see some additional denials now (accessing /etc/resolv.conf, communication with sssd), but as they do not seem to have any impact on the commands, I'd rather push the existing PR. > It does need to read various configuration bits spread across /etc, > /usr/lib/rpm and home directory (but ~/.rpmmacros and ~/.popt are not > critical for operation normally). It will not *write* anywhere besides the > rpmdb path at given root, but of course ultimately both the database path > and the root are both configurable and cli-overridable, and also > configuration path can be diverted on the cli. > > As for --exportdb and --importdb, they operate on stdin/stdout, the target > file is opened by the invoking shell. Reading of all ^^^ mentioned files and writing to common places should be allowed now. Villy, Thank you for the additional reports. > For some unknown reason rpmdb wants to read /etc/resolv.conf.
Rpm does dummy name service lookups on librpm initialization to force early dlopen()'s in case it needs to chroot as it can't obviously load anything from the chroot. That said, it doesn't need host name services at all (just user/group names) so the dummy gethostbyname() could likely be dropped. And in fact, library initialization is a silly place to do this when it could just as well do it much later, I'll look into that.
Disallowing all that shouldn't affect rpmdb command at all.
*** Bug 1895587 has been marked as a duplicate of this bug. *** FEDORA-2020-77b49aa207 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-77b49aa207 FEDORA-2020-77b49aa207 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-77b49aa207` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-77b49aa207 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. *** Bug 1894791 has been marked as a duplicate of this bug. *** Similar problem has been detected: something crashed and abrt tries to capture info from the crash, I think? hashmarkername: setroubleshoot kernel: 5.8.17-300.fc33.x86_64 reason: SELinux is preventing abrt-action-sav from 'write' accesses on the file /var/lib/rpm/rpmdb.sqlite-shm. type: libreport I'm not sure what the cause was, but I was getting that on a laptop I upgraded from F32 to F33. I was getting endless notifications until I ran the restorecon and stopped the troubleshooter. I will be holding off on any remote upgrades until I'm sure this issue is resolved. selinux-policy-3.14.6-30.fc33.noarch has shown up in Fedora 33 updates repository, so the issue should be fixed by now -- including upgrading from fc32 to fc31. It looks like selinux-policy-3.14.6-30.fc33.noarch does an execellent job. I installed this morning; no SELinux errors, no high cpu load. Super! Similar problem has been detected: On startup in background hashmarkername: setroubleshoot kernel: 5.8.18-300.fc33.x86_64 reason: SELinux is preventing abrt-action-sav from 'setattr' accesses on the file /var/lib/rpm/rpmdb.sqlite-wal. type: libreport (In reply to W. de Heiden from comment #81) > It looks like selinux-policy-3.14.6-30.fc33.noarch does an execellent job. I > installed this morning; no SELinux errors, no high cpu load. Super! I'm still seeing this behaviour with that version: [sloppy]# dnf list installed | grep selinux-policy selinux-policy.noarch 3.14.6-30.fc33 @updates selinux-policy-targeted.noarch 3.14.6-30.fc33 @updates [sloppy]# (In reply to Tony from comment #83) > (In reply to W. de Heiden from comment #81) > > It looks like selinux-policy-3.14.6-30.fc33.noarch does an execellent job. I > > installed this morning; no SELinux errors, no high cpu load. Super! > > I'm still seeing this behaviour with that version: > > [sloppy]# dnf list installed | grep selinux-policy > selinux-policy.noarch 3.14.6-30.fc33 > @updates > selinux-policy-targeted.noarch 3.14.6-30.fc33 > @updates > [sloppy]# Did you upgrade to fc33 after or before 3.14.6-30.fc33 became available? Checking logs, I upgraded the v32 system on 2020-10-31 and it installed 3.14.6.29.fc33 (upgraded from 3.14.5-44.fc32) so I'd say before. (In reply to Tony from comment #85) > Checking logs, I upgraded the v32 system on 2020-10-31 and it installed > 3.14.6.29.fc33 (upgraded from 3.14.5-44.fc32) so I'd say before. You should run sudo rpmdb --rebuilddb and I would expect the SELinux labels will be done correctly. What happens during upgrade is that the rpm database is coverted from Berkeley DB to lightdm using rpmdb --rebuilddb, and this is in this case done with the old version of rpm. Thus, the new version rpm does not help you unless you rebuild the rpm database again using the new version. For those that haven't upgraded yout should not see this problem during upgrade. For the full details you can read all the other comments in this error report. (In reply to Villy Kruse from comment #86) > (In reply to Tony from comment #85) > > Checking logs, I upgraded the v32 system on 2020-10-31 and it installed > > 3.14.6.29.fc33 (upgraded from 3.14.5-44.fc32) so I'd say before. > > You should run > > sudo rpmdb --rebuilddb > > and I would expect the SELinux labels will be done correctly. > > What happens during upgrade is that the rpm database is coverted from > Berkeley DB to lightdm using rpmdb --rebuilddb, and this is in this case > done with the old version of rpm. Thus, the new version rpm does not help > you unless you rebuild the rpm database again using the new version. > > For those that haven't upgraded yout should not see this problem during > upgrade. For the full details you can read all the other comments in this > error report. Thanks, I just skipped to the bottom! (In reply to Villy Kruse from comment #86) > (In reply to Tony from comment #85) > > Checking logs, I upgraded the v32 system on 2020-10-31 and it installed > > 3.14.6.29.fc33 (upgraded from 3.14.5-44.fc32) so I'd say before. > > You should run > > sudo rpmdb --rebuilddb > > and I would expect the SELinux labels will be done correctly. > > What happens during upgrade is that the rpm database is coverted from > Berkeley DB to lightdm using rpmdb --rebuilddb, and this is in this case > done with the old version of rpm. Thus, the new version rpm does not help > you unless you rebuild the rpm database again using the new version. > > For those that haven't upgraded yout should not see this problem during > upgrade. For the full details you can read all the other comments in this > error report. Though that had absolutely no effect on two affected hosts. It didn't appear to rebuild anything, in fact. I'll have more time to look into this later in the week. (In reply to Tony from comment #88) > (In reply to Villy Kruse from comment #86) > > (In reply to Tony from comment #85) > > > Checking logs, I upgraded the v32 system on 2020-10-31 and it installed > > > 3.14.6.29.fc33 (upgraded from 3.14.5-44.fc32) so I'd say before. > > > > You should run > > > > sudo rpmdb --rebuilddb > > > > and I would expect the SELinux labels will be done correctly. > > > > What happens during upgrade is that the rpm database is coverted from > > Berkeley DB to lightdm using rpmdb --rebuilddb, and this is in this case > > done with the old version of rpm. Thus, the new version rpm does not help > > you unless you rebuild the rpm database again using the new version. > > > > For those that haven't upgraded yout should not see this problem during > > upgrade. For the full details you can read all the other comments in this > > error report. > > Though that had absolutely no effect on two affected hosts. It didn't appear > to rebuild anything, in fact. I'll have more time to look into this later in > the week. Ahh. Still need to apply restorecon -RFv /var/lib/rpm (In reply to Tony from comment #88) > > Though that had absolutely no effect on two affected hosts. It didn't appear > to rebuild anything, in fact. I'll have more time to look into this later in > the week. That is correct. It only works with SELinux in permissive mode. type=AVC msg=audit(1605506761.594:180): avc: denied { create } for pid=985 comm="rpmdb" name=".rpm.lock" scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1605506761.595:181): avc: denied { open } for pid=985 comm="rpmdb" path="/var/lib/rpm/.rpm.lock" dev="sda2" ino=526103 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1605506761.595:182): avc: denied { lock } for pid=985 comm="rpmdb" path="/var/lib/rpm/.rpm.lock" dev="sda2" ino=526103 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1605506761.597:183): avc: denied { getattr } for pid=985 comm="rpmdb" path="/var/lib/rpm/rpmdb.sqlite" dev="sda2" ino=525577 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1605506761.597:184): avc: denied { setattr } for pid=985 comm="rpmdb" name="rpmdb.sqlite-wal" dev="sda2" ino=526101 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1605506761.598:185): avc: denied { map } for pid=985 comm="rpmdb" path="/var/lib/rpm/rpmdb.sqlite-shm" dev="sda2" ino=525789 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1605506765.540:187): avc: denied { read } for pid=987 comm="rpm" name="rpmdb.sqlite" dev="sda2" ino=525577 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1605506765.540:188): avc: denied { open } for pid=987 comm="rpm" path="/var/lib/rpm/rpmdb.sqlite" dev="sda2" ino=525577 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1605506765.540:189): avc: denied { lock } for pid=987 comm="rpm" path="/var/lib/rpm/rpmdb.sqlite" dev="sda2" ino=525577 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1605506765.540:190): avc: denied { map } for pid=987 comm="rpm" path="/var/lib/rpm/rpmdb.sqlite-shm" dev="sda2" ino=525789 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1605506771.857:193): avc: denied { rename } for pid=985 comm="rpmdb" name="rpm" dev="sda2" ino=524388 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=dir permissive=1 type=AVC msg=audit(1605506771.860:194): avc: denied { unlink } for pid=985 comm="rpmdb" name="rpmdb.sqlite" dev="sda2" ino=525577 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1605506771.879:195): avc: denied { rmdir } for pid=985 comm="rpmdb" name="rpmold.985" dev="sda2" ino=524388 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=dir permissive=1 (In reply to Villy Kruse from comment #86) > What happens during upgrade is that the rpm database is coverted from > Berkeley DB to lightdm using rpmdb --rebuilddb, and this is in this case > done with the old version of rpm. Thus, the new version rpm does not help > you unless you rebuild the rpm database again using the new version. Sorry but that's not at all what happens. The rpm database is converted to the new sqlite format on the first boot to Fedora 33. The old rpm version in Fedora 32 doesn't know anything at all of the new format so it couldn't be used for the db rebuild. My expectations are as follows: 1. If Fedora was updated with selinux-policy prior to selinux-policy-3.14.6-30.fc33, the rpm database should be converted to the new format, but the labels on /var/lib/rpm can be incorrect. The only action needed is # restorecon -Rv /var/lib/rpm to restore context according to default setting. 2. With selinux-policy-3.14.6-30.fc33 and newer, no action is needed. Since then, any database rebuild should complete successfully in selinux enforcing mode. If your experience is different, please report it here or file a new bug. The fix will be backported to f32 soon. (In reply to Panu Matilainen from comment #91) > (In reply to Villy Kruse from comment #86) > > What happens during upgrade is that the rpm database is coverted from > > Berkeley DB to lightdm using rpmdb --rebuilddb, and this is in this case > > done with the old version of rpm. Thus, the new version rpm does not help > > you unless you rebuild the rpm database again using the new version. > > Sorry but that's not at all what happens. > > The rpm database is converted to the new sqlite format on the first boot to > Fedora 33. > > The old rpm version in Fedora 32 doesn't know anything at all of the new > format so it couldn't be used for the db rebuild. That is correct. What I meant to say is that if the old version of fc33 rpm is doing the conversion, the SELinux will not be correctly set. So you would need to fix it using the restorecon program. (In reply to Zdenek Pytela from comment #92) > My expectations are as follows: > > 1. If Fedora was updated with selinux-policy prior to > selinux-policy-3.14.6-30.fc33, the rpm database should be converted to the > new format, but the labels on /var/lib/rpm can be incorrect. The only action > needed is > > # restorecon -Rv /var/lib/rpm > > to restore context according to default setting. > > 2. With selinux-policy-3.14.6-30.fc33 and newer, no action is needed. Since > then, any database rebuild should complete successfully in selinux enforcing > mode. > > If your experience is different, please report it here or file a new bug. > > The fix will be backported to f32 soon. The upgrade may fail if the rpm database files are not labeled correctly before the upgrade. Other than that it works perfectly. > What I meant to say is that if the old version of fc33 rpm is doing the conversion, the SELinux will not be correctly set. So you would need to fix it using the restorecon program.
I suppose what you really meant is "if the old version of fc33 selinux-policy rpm is active during the conversion", because there are no updates to rpm itself involved.
Similar problem has been detected: This happens about 500 times on login to gnome. I assume dnf update is running in the background. hashmarkername: setroubleshoot kernel: 5.8.18-300.fc33.x86_64 reason: SELinux is preventing abrt-action-sav from 'setattr' accesses on the file /var/lib/rpm/rpmdb.sqlite-wal. type: libreport *** Bug 1899959 has been marked as a duplicate of this bug. *** Similar problem has been detected: coredumps not working it seems hashmarkername: setroubleshoot kernel: 5.9.8-200.fc33.x86_64 package: selinux-policy-targeted-3.14.6-30.fc33.noarch reason: SELinux is preventing abrt-action-sav from 'setattr' accesses on the file /var/lib/rpm/rpmdb.sqlite-wal. type: libreport Similar problem has been detected: Open & decrypt XCA database hashmarkername: setroubleshoot kernel: 5.9.9-200.fc33.x86_64 reason: SELinux is preventing abrt-action-lis from 'write' accesses on the file /var/lib/rpm/rpmdb.sqlite-wal. type: libreport FEDORA-2020-77b49aa207 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. *** Bug 1887334 has been marked as a duplicate of this bug. *** Hi got this Problem:
Is this the same?:
Whats described there doesnt work 4 me.
SELinux hindert abrt-action-lis daran, mit write-Zugriff auf Datei /var/lib/rpm/rpmdb.sqlite-wal zuzugreifen.
***** Plugin restorecon (94.8 Wahrscheinlichkeit) schlägt vor ************
Wenn Sie das Etikett reparieren möchten./var/lib/rpm/rpmdb.sqlite-wal Default Label sollte sein rpm_var_lib_t.
Dann sie können restorecon ausführen. Der Zugriffsversuch wurde möglicherweise aufgrund unzureichender Berechtigungen für den Zugriff auf ein übergeordnetes Verzeichnis angehalten. Versuchen Sie in diesem Fall, den folgenden Befehl entsprechend zu ändern.
Ausführen
# /sbin/restorecon -v /var/lib/rpm/rpmdb.sqlite-wal
***** Plugin catchall_labels (5.21 Wahrscheinlichkeit) schlägt vor *******
Wenn Sie erlauben wollen, dass abrt-action-lis write Zugriff auf rpmdb.sqlite-wal file
Dann sie müssen das Label auf /var/lib/rpm/rpmdb.sqlite-wal ändern
Ausführen
# semanage fcontext -a -t FILE_TYPE '/var/lib/rpm/rpmdb.sqlite-wal'
wobei FILE_TYPE einer der folgenen Werte ist: abrt_etc_t, abrt_tmp_t, abrt_upload_watch_tmp_t, abrt_var_cache_t, abrt_var_log_t, abrt_var_run_t, afs_cache_t, initrc_tmp_t, kdump_crash_t, mail_home_rw_t, mock_var_lib_t, postfix_postdrop_t, puppet_tmp_t, rhsmcertd_var_run_t, rpm_log_t, rpm_var_cache_t, rpm_var_run_t, sysfs_t, user_cron_spool_t, user_tmp_t, usr_t.
Führen Sie danach Folgendes aus:
restorecon -v '/var/lib/rpm/rpmdb.sqlite-wal'
***** Plugin catchall (1.44 Wahrscheinlichkeit) schlägt vor **************
Wenn Sie denken, dass es abrt-action-lis standardmäßig erlaubt sein sollte, write Zugriff auf rpmdb.sqlite-wal file zu erhalten.
Dann sie sollten dies als Fehler melden.
Um diesen Zugriff zu erlauben, können Sie ein lokales Richtlinien-Modul erstellen.
Ausführen
zugriff jetzt erlauben, indem Sie die nachfolgenden Befehle ausführen:
# ausearch -c 'abrt-action-lis' --raw | audit2allow -M my-abrtactionlis
# semodule -X 300 -i my-abrtactionlis.pp
zusätzliche Information:
Quellkontext system_u:system_r:abrt_t:s0-s0:c0.c1023
Zielkontext system_u:object_r:var_lib_t:s0
Zielobjekte /var/lib/rpm/rpmdb.sqlite-wal [ file ]
Quelle abrt-action-lis
Quellpfad abrt-action-lis
Port
RPM-Pakete der Quelle
RPM-Pakete des Ziels
SELinux Policy RPM <Unbekannt>
Local Policy RPM selinux-policy-targeted-3.14.6-30.fc33.noarch
SELinux aktiviert True
Richtlinientyp targeted
Enforcing-Modus Enforcing
Rechnername
Plattform Linux dedui26-lxl009 5.9.9-200.fc33.x86_64 #1 SMP
Thu Nov 19 21:25:45 UTC 2020 x86_64 x86_64
Anzahl der Alarme 16
Zuerst gesehen 2020-11-26 10:23:01 CET
Zuletzt gesehen 2020-11-26 10:23:01 CET
Lokale ID 6504276e-f918-43a3-8c8d-350eeec23d42
Raw-Audit-Meldungen
type=AVC msg=audit(1606382581.998:38844): avc: denied { write } for pid=78507 comm="abrt-action-lis" name="rpmdb.sqlite-wal" dev="dm-1" ino=4325883 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0
Hash: abrt-action-lis,abrt_t,var_lib_t,file,write
(In reply to Pressluft from comment #102) > Hi got this Problem: > > Is this the same?: > Whats described there doesnt work 4 me. Hi, If the policy was rebuilt before the selinux-policy package update, you need to restore context, as suggested by the restorecon plugin: > > > > SELinux hindert abrt-action-lis daran, mit write-Zugriff auf Datei > /var/lib/rpm/rpmdb.sqlite-wal zuzugreifen. > > ***** Plugin restorecon (94.8 Wahrscheinlichkeit) schlägt vor > ************ > > Wenn Sie das Etikett reparieren möchten./var/lib/rpm/rpmdb.sqlite-wal > Default Label sollte sein rpm_var_lib_t. > Dann sie können restorecon ausführen. Der Zugriffsversuch wurde > möglicherweise aufgrund unzureichender Berechtigungen für den Zugriff auf > ein übergeordnetes Verzeichnis angehalten. Versuchen Sie in diesem Fall, den > folgenden Befehl entsprechend zu ändern. > Ausführen > # /sbin/restorecon -v /var/lib/rpm/rpmdb.sqlite-wal ^^^ here. You'd rather run it for the directory: # /sbin/restorecon -Rv /var/lib/rpm > > ***** Plugin catchall_labels (5.21 Wahrscheinlichkeit) schlägt vor > ******* > > Wenn Sie erlauben wollen, dass abrt-action-lis write Zugriff auf > rpmdb.sqlite-wal file > Dann sie müssen das Label auf /var/lib/rpm/rpmdb.sqlite-wal ändern > Ausführen > # semanage fcontext -a -t FILE_TYPE '/var/lib/rpm/rpmdb.sqlite-wal' > wobei FILE_TYPE einer der folgenen Werte ist: abrt_etc_t, abrt_tmp_t, > abrt_upload_watch_tmp_t, abrt_var_cache_t, abrt_var_log_t, abrt_var_run_t, > afs_cache_t, initrc_tmp_t, kdump_crash_t, mail_home_rw_t, mock_var_lib_t, > postfix_postdrop_t, puppet_tmp_t, rhsmcertd_var_run_t, rpm_log_t, > rpm_var_cache_t, rpm_var_run_t, sysfs_t, user_cron_spool_t, user_tmp_t, > usr_t. > Führen Sie danach Folgendes aus: > restorecon -v '/var/lib/rpm/rpmdb.sqlite-wal' > > > ***** Plugin catchall (1.44 Wahrscheinlichkeit) schlägt vor > ************** > > Wenn Sie denken, dass es abrt-action-lis standardmäßig erlaubt sein sollte, > write Zugriff auf rpmdb.sqlite-wal file zu erhalten. > Dann sie sollten dies als Fehler melden. > Um diesen Zugriff zu erlauben, können Sie ein lokales Richtlinien-Modul > erstellen. > Ausführen > zugriff jetzt erlauben, indem Sie die nachfolgenden Befehle ausführen: > # ausearch -c 'abrt-action-lis' --raw | audit2allow -M my-abrtactionlis > # semodule -X 300 -i my-abrtactionlis.pp > > zusätzliche Information: > Quellkontext system_u:system_r:abrt_t:s0-s0:c0.c1023 > Zielkontext system_u:object_r:var_lib_t:s0 > Zielobjekte /var/lib/rpm/rpmdb.sqlite-wal [ file ] > Quelle abrt-action-lis > Quellpfad abrt-action-lis > Port > > RPM-Pakete der Quelle > RPM-Pakete des Ziels > SELinux Policy RPM <Unbekannt> > Local Policy RPM selinux-policy-targeted-3.14.6-30.fc33.noarch > SELinux aktiviert True > Richtlinientyp targeted > Enforcing-Modus Enforcing > Rechnername > Plattform Linux dedui26-lxl009 5.9.9-200.fc33.x86_64 #1 > SMP > Thu Nov 19 21:25:45 UTC 2020 x86_64 x86_64 > Anzahl der Alarme 16 > Zuerst gesehen 2020-11-26 10:23:01 CET > Zuletzt gesehen 2020-11-26 10:23:01 CET > Lokale ID 6504276e-f918-43a3-8c8d-350eeec23d42 > > Raw-Audit-Meldungen > type=AVC msg=audit(1606382581.998:38844): avc: denied { write } for > pid=78507 comm="abrt-action-lis" name="rpmdb.sqlite-wal" dev="dm-1" > ino=4325883 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 > > > Hash: abrt-action-lis,abrt_t,var_lib_t,file,write (In reply to Zdenek Pytela from comment #103) > (In reply to Pressluft from comment #102) > > Hi got this Problem: > > > > Is this the same?: > > Whats described there doesnt work 4 me. > Hi, > > If the policy was rebuilt before the selinux-policy package update, you need > to restore context, as suggested by the restorecon plugin: > > > > > > > > > SELinux hindert abrt-action-lis daran, mit write-Zugriff auf Datei > > /var/lib/rpm/rpmdb.sqlite-wal zuzugreifen. > > > > ***** Plugin restorecon (94.8 Wahrscheinlichkeit) schlägt vor > > ************ > > > > Wenn Sie das Etikett reparieren möchten./var/lib/rpm/rpmdb.sqlite-wal > > Default Label sollte sein rpm_var_lib_t. > > Dann sie können restorecon ausführen. Der Zugriffsversuch wurde > > möglicherweise aufgrund unzureichender Berechtigungen für den Zugriff auf > > ein übergeordnetes Verzeichnis angehalten. Versuchen Sie in diesem Fall, den > > folgenden Befehl entsprechend zu ändern. > > Ausführen > > # /sbin/restorecon -v /var/lib/rpm/rpmdb.sqlite-wal > ^^^ here. You'd rather run it for the directory: > > # /sbin/restorecon -Rv /var/lib/rpm > > > > > ***** Plugin catchall_labels (5.21 Wahrscheinlichkeit) schlägt vor > > ******* > > > > Wenn Sie erlauben wollen, dass abrt-action-lis write Zugriff auf > > rpmdb.sqlite-wal file > > Dann sie müssen das Label auf /var/lib/rpm/rpmdb.sqlite-wal ändern > > Ausführen > > # semanage fcontext -a -t FILE_TYPE '/var/lib/rpm/rpmdb.sqlite-wal' > > wobei FILE_TYPE einer der folgenen Werte ist: abrt_etc_t, abrt_tmp_t, > > abrt_upload_watch_tmp_t, abrt_var_cache_t, abrt_var_log_t, abrt_var_run_t, > > afs_cache_t, initrc_tmp_t, kdump_crash_t, mail_home_rw_t, mock_var_lib_t, > > postfix_postdrop_t, puppet_tmp_t, rhsmcertd_var_run_t, rpm_log_t, > > rpm_var_cache_t, rpm_var_run_t, sysfs_t, user_cron_spool_t, user_tmp_t, > > usr_t. > > Führen Sie danach Folgendes aus: > > restorecon -v '/var/lib/rpm/rpmdb.sqlite-wal' > > > > > > ***** Plugin catchall (1.44 Wahrscheinlichkeit) schlägt vor > > ************** > > > > Wenn Sie denken, dass es abrt-action-lis standardmäßig erlaubt sein sollte, > > write Zugriff auf rpmdb.sqlite-wal file zu erhalten. > > Dann sie sollten dies als Fehler melden. > > Um diesen Zugriff zu erlauben, können Sie ein lokales Richtlinien-Modul > > erstellen. > > Ausführen > > zugriff jetzt erlauben, indem Sie die nachfolgenden Befehle ausführen: > > # ausearch -c 'abrt-action-lis' --raw | audit2allow -M my-abrtactionlis > > # semodule -X 300 -i my-abrtactionlis.pp > > > > zusätzliche Information: > > Quellkontext system_u:system_r:abrt_t:s0-s0:c0.c1023 > > Zielkontext system_u:object_r:var_lib_t:s0 > > Zielobjekte /var/lib/rpm/rpmdb.sqlite-wal [ file ] > > Quelle abrt-action-lis > > Quellpfad abrt-action-lis > > Port > > > > RPM-Pakete der Quelle > > RPM-Pakete des Ziels > > SELinux Policy RPM <Unbekannt> > > Local Policy RPM selinux-policy-targeted-3.14.6-30.fc33.noarch > > SELinux aktiviert True > > Richtlinientyp targeted > > Enforcing-Modus Enforcing > > Rechnername > > Plattform Linux dedui26-lxl009 5.9.9-200.fc33.x86_64 #1 > > SMP > > Thu Nov 19 21:25:45 UTC 2020 x86_64 x86_64 > > Anzahl der Alarme 16 > > Zuerst gesehen 2020-11-26 10:23:01 CET > > Zuletzt gesehen 2020-11-26 10:23:01 CET > > Lokale ID 6504276e-f918-43a3-8c8d-350eeec23d42 > > > > Raw-Audit-Meldungen > > type=AVC msg=audit(1606382581.998:38844): avc: denied { write } for > > pid=78507 comm="abrt-action-lis" name="rpmdb.sqlite-wal" dev="dm-1" > > ino=4325883 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 > > tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 > > > > > > Hash: abrt-action-lis,abrt_t,var_lib_t,file,write Perfect that was the solution! Failure seemed to be gone....! thx!!! I did an update from F32 to F33 today, with a full DNF upgrade before the update and install, and still had to do "sudo restorecon -RFv /var/lib/rpm" afterwards to get the rpmdb correctly converted to SQLite (as described in https://bugzilla.redhat.com/show_bug.cgi?id=1836108#c25 ). The logs for the pre-upgrade update show that F32 had been updated to 3.14.5-45, as noted in the ERRATA entry above: ======== selinux-policy noarch 3.14.5-45.fc32 updates 77 k selinux-policy-targeted noarch 3.14.5-45.fc32 updates 8.0 M ======== While the upgrade itself installs 3.14.6: ======== selinux-policy noarch 3.14.6-30.fc33 updates 84 k selinux-policy-targeted noarch 3.14.6-30.fc33 updates 8.0 M ======== Just did a clean install of F32, updated, then upgrade to F33 - and the conversion to sqlite succeeds. I didn't run restorecon at any time. And the journal doesn't have any avc errors. -rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0 68513792 Dec 5 03:38 rpmdb.sqlite -rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0 32768 Dec 5 03:39 rpmdb.sqlite-shm -rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0 0 Dec 5 03:38 rpmdb.sqlite-wal I was building a new Fedora/RISCV f33 disk image and noticed this: [..] 181ksetfiles: Could not set context for /usr/bin/rpmdb: Invalid argument DEBUG util.py:598: / 100.0% DEBUG util.py:596: Unable to create appliance : SELinux relabel failed. [..] I checked and repo has selinux-policy-3.14.6-30.fc33 I am using rpm-4.16.0-5.fc33 which is still in which is still in f33-updates-testing. Similar problem has been detected: This happens when nautilus crashes and abrt is trying to report. Also it causes high single-thread CPU usage by setroubleshootd process and I do not know how to stop it without reboot. hashmarkername: setroubleshoot kernel: 5.9.8-200.fc33.x86_64 reason: SELinux is preventing abrt-action-sav from 'setattr' accesses on the file /var/lib/rpm/rpmdb.sqlite-wal. type: libreport Similar problem has been detected: This happens when nautilus crashes and abrt is trying to report. Also it causes high single-thread CPU usage by setroubleshootd process and I do not know how to stop it without reboot. hashmarkername: setroubleshoot kernel: 5.9.8-200.fc33.x86_64 reason: SELinux is preventing abrt-action-sav from 'write' accesses on the file /var/lib/rpm/rpmdb.sqlite-wal. type: libreport (In reply to Zdenek Pytela from comment #66) > Folks, > > I finished the policy patches and have a copr build which seems to work as > expected, i. e. rpmdb --rebuilddb creates the directory with correct type > both from console and systemd service unit. > > The build is for rawhide only, but local build works for F33, too: > https://copr.fedorainfracloud.org/coprs/zpytela/selinux-policy/build/1743918/ > > Lukasi, > > You mentioned you have unit tests. Can you use them to test the build? I wrote that 3 years ago: "Lukas Slebodnik 2017-08-12 19:23:51 UTC" Sorry I do not remember details aymore. > > Lukasi,
> >
> > You mentioned you have unit tests. Can you use them to test the build?
>
> I wrote that 3 years ago: "Lukas Slebodnik 2017-08-12 19:23:51 UTC"
>
> Sorry I do not remember details aymore.
I absolutely understand, we now anyway have the changes in Fedora 32+ and additional reports come. Thank you for your effort in isolating this issue.
(In reply to Nick Coghlan from comment #105) > I did an update from F32 to F33 today, with a full DNF upgrade before the > update and install, and still had to do "sudo restorecon -RFv /var/lib/rpm" > afterwards to get the rpmdb correctly converted to SQLite (as described in > https://bugzilla.redhat.com/show_bug.cgi?id=1836108#c25 ). The same for me. I did upgrade from F31 to F32 on 2020-12-08 and I did upgrade from F32 to F33 today (2020-12-25), both times with calling "dnf update --refresh" (or actually a safer equivalent command "pkcon refresh force && pkcon update --only-download && pkcon offline-trigger && systemctl reboot") before and after the upgrade. My system is several years old, originally installed as F25 in March 2017 and gradually upgraded in +1 steps over the years. I know that I did run `rpm --rebuilddb` manually right after the upgrade from F30 to F31, and the command did run silently at that time (with no success of error messages), but I think that the run was successful (it fixed an issue with broken database). I think that this issue with "rpmdb --rebuilddb" shall be listed on the Common F33 bugs page, https://fedoraproject.org/wiki/Common_F33_bugs I see that this bug has already been tagged with CommonBugs keyword. Here is additional information to help updating the Wiki, as requested by "My bug is not listed" section of the Wiki page: > a summary of the problem # Upgrade issues / RPM fails to convert Packages database from bdb to sqlite backend, DNF prints a warning With Fedora 33 the RPM packages database is being switched over from Berkeley DB to a new Sqlite format. (Reference: [1]) On some systems this change does not happen automatically, and an attempt to rebuild the database manually fails as well. For administrators it manifests in the following way: - Any dnf command is accompanied with one or more occurrences of a warning: [2] # dnf update warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. - An attempt to fix the database by running `rpmdb --rebuilddb` command fails: # rpmdb --rebuilddb error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Permission denied) The root cause is that SELinux denies `rpmdb` an access to the files. [3] As a result, `rpmdb` fails to run during an upgrade and when run manually. > any known workarounds 1. Run the following command, to reset SELinux security context on the files used by RPM: # restorecon -RFv /var/lib/rpm The output looks like the following: # restorecon -RFv /var/lib/rpm Relabeled /var/lib/rpm/Enhancename from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/Suggestname from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/__db.001 from unconfined_u:object_r:rpm_var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/Sha1header from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/Supplementname from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/Basenames from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/Name from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/Recommendname from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/__db.002 from unconfined_u:object_r:rpm_var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/Packages from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/Providename from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/Dirnames from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/Triggername from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/Obsoletename from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/.rpm.lock from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/Transfiletriggername from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/Sigmd5 from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/.dbenv.lock from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/Filetriggername from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/__db.003 from unconfined_u:object_r:rpm_var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/Conflictname from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/Group from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/Requirename from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/Installtid from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 2. Run rpmdb to rebuild the RPM database: # rpmdb --rebuilddb The output looks like the following: # rpmdb --rebuilddb warning: Converting database from bdb to sqlite backend As can be seen, the rpmdb command completed successfully. > an assessment on the impact to Fedora users This issue has no impact on new installations of Fedora 33. It affects some upgraded installations. (Judging by comment 1461313#c106 it looks that it does not affect systems that were originally installed as Fedora 32. The bug 1461313 itself was filed during an upgrade from F25 to F26 (comment #5 and comment #8), and my system originally was a F25 one.) [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YYOEZO2FO2E2T6KO25434EBDTIOWK5OM/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=1836108 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1461313#c27 (In reply to Konstantin Kolinko from comment #112) > (In reply to Nick Coghlan from comment #105) > > I did an update from F32 to F33 today, with a full DNF upgrade before the > > update and install, and still had to do "sudo restorecon -RFv /var/lib/rpm" > > afterwards to get the rpmdb correctly converted to SQLite (as described in > > https://bugzilla.redhat.com/show_bug.cgi?id=1836108#c25 ). > > The same for me. > I did upgrade from F31 to F32 on 2020-12-08 and > I did upgrade from F32 to F33 today (2020-12-25), > both times with calling "dnf update --refresh" (or actually a safer > equivalent command "pkcon refresh force && pkcon update --only-download && > pkcon offline-trigger && systemctl reboot") before and after the upgrade. > It would help a lot if rpmdb would be given permission to read files labeled as "var_lib_t". Notice that rpm itself does have that permission. As it is, if "rpmdb --rebuild" is ever run in the past people will keep running into this problem, unless the run the restorecon command. By the way, rebuilding the rpm data base was in the past quite useful when rpm has become rather slow. Similar problem has been detected: I did a yum update and the following selinux warnings appeared. hashmarkername: setroubleshoot kernel: 5.9.13-200.fc33.x86_64 reason: SELinux is preventing abrt-action-lis from 'write' accesses on the file /var/lib/rpm/rpmdb.sqlite-wal. type: libreport What is the final workaround/fix for this? restorecon /var/lib/rpm didn't seem to help. This is driving me nuts, I'm getting a constant spam of these notifications without ever stopping. I still have avc denials but they don't seem to inhibit rebuilding the rpmdb, looks like the denials on { open } are no longer happening following relabel.
$ sudo rpm --rebuilddb
error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Permission denied)
[44245.089959] sudo[37440]: chris : TTY=pts/3 ; PWD=/home/chris ; USER=root ; COMMAND=/usr/bin/rpm --rebuilddb
[44245.090682] audit[37440]: CRED_REFR pid=37440 uid=0 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/3 res=success'
[44245.093725] sudo[37440]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
[44245.094390] audit[37440]: USER_START pid=37440 uid=0 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/3 res=success'
[44245.101223] audit[37442]: AVC avc: denied { read } for pid=37442 comm="rpmdb" name="resolv.conf" dev="nvme0n1p7" ino=5229864 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:net_conf_t:s0 tclass=lnk_file permissive=0
[44245.101329] audit[37442]: AVC avc: denied { read } for pid=37442 comm="rpmdb" name="resolv.conf" dev="nvme0n1p7" ino=5229864 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:net_conf_t:s0 tclass=lnk_file permissive=0
[44245.101675] audit[37442]: AVC avc: denied { create } for pid=37442 comm="rpmdb" scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tclass=udp_socket permissive=0
[44245.101735] audit[37442]: AVC avc: denied { create } for pid=37442 comm="rpmdb" scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tclass=udp_socket permissive=0
[44245.104901] audit[37442]: AVC avc: denied { open } for pid=37442 comm="rpmdb" path="/var/lib/rpm/.rpm.lock" dev="nvme0n1p7" ino=5278371 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=0
[44245.104999] audit[37442]: AVC avc: denied { open } for pid=37442 comm="rpmdb" path="/var/lib/rpm/.rpm.lock" dev="nvme0n1p7" ino=5278371 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=0
[44245.106017] sudo[37440]: pam_unix(sudo:session): session closed for user root
$ sudo restorecon -Rv /var
...
Relabeled /var/lib/rpm/rpmdb.sqlite from unconfined_u:object_r:var_lib_t:s0 to unconfined_u:object_r:rpm_var_lib_t:s0
Relabeled /var/lib/rpm/rpmdb.sqlite-wal from unconfined_u:object_r:var_lib_t:s0 to unconfined_u:object_r:rpm_var_lib_t:s0
Relabeled /var/lib/rpm/rpmdb.sqlite-shm from unconfined_u:object_r:var_lib_t:s0 to unconfined_u:object_r:rpm_var_lib_t:s0
Relabeled /var/lib/rpm/.rpm.lock from unconfined_u:object_r:var_lib_t:s0 to unconfined_u:object_r:rpm_var_lib_t:s0
$ sudo rpm --rebuilddb
[chris@flap ~]$ ls -lZ /var/lib/rpm
total 135156
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0 137875456 Dec 29 00:54 rpmdb.sqlite
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0 524288 Dec 29 00:54 rpmdb.sqlite-shm
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0 0 Dec 29 00:54 rpmdb.sqlite-wal
$
[44558.404174] sudo[37855]: chris : TTY=pts/3 ; PWD=/home/chris ; USER=root ; COMMAND=/usr/bin/rpm --rebuilddb
[44558.405115] audit[37855]: CRED_REFR pid=37855 uid=0 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/3 res=success'
[44558.410976] sudo[37855]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
[44558.411717] audit[37855]: USER_START pid=37855 uid=0 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/3 res=success'
[44558.420965] audit[37857]: AVC avc: denied { read } for pid=37857 comm="rpmdb" name="resolv.conf" dev="nvme0n1p7" ino=5229864 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:net_conf_t:s0 tclass=lnk_file permissive=0
[44558.421072] audit[37857]: AVC avc: denied { read } for pid=37857 comm="rpmdb" name="resolv.conf" dev="nvme0n1p7" ino=5229864 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:net_conf_t:s0 tclass=lnk_file permissive=0
[44558.421374] audit[37857]: AVC avc: denied { create } for pid=37857 comm="rpmdb" scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tclass=udp_socket permissive=0
[44558.421425] audit[37857]: AVC avc: denied { create } for pid=37857 comm="rpmdb" scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tclass=udp_socket permissive=0
[44562.278633] sudo[37855]: pam_unix(sudo:session): session closed for user root
[44562.279075] audit[37855]: USER_END pid=37855 uid=0 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/3 res=success'
[44562.279151] audit[37855]: CRED_DISP pid=37855 uid=0 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="roo
(In reply to Chris Murphy from comment #116) > I still have avc denials but they don't seem to inhibit rebuilding the > rpmdb, looks like the denials on { open } are no longer happening following > relabel. > .............. See comment 73 for the explanation of the following AVC denials. None of those affects rpmdb --rebuilddb and at least one of them are fixed in the latest version of selinux-policy. > > $ > [44558.404174] sudo[37855]: chris : TTY=pts/3 ; PWD=/home/chris ; > USER=root ; COMMAND=/usr/bin/rpm --rebuilddb > [44558.405115] audit[37855]: CRED_REFR pid=37855 uid=0 auid=1000 ses=3 > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/3 res=success' > [44558.410976] sudo[37855]: pam_unix(sudo:session): session opened for user > root(uid=0) by (uid=0) > [44558.411717] audit[37855]: USER_START pid=37855 uid=0 auid=1000 ses=3 > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:session_open > grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix > acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/3 > res=success' > [44558.420965] audit[37857]: AVC avc: denied { read } for pid=37857 > comm="rpmdb" name="resolv.conf" dev="nvme0n1p7" ino=5229864 > scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:net_conf_t:s0 tclass=lnk_file permissive=0 > [44558.421072] audit[37857]: AVC avc: denied { read } for pid=37857 > comm="rpmdb" name="resolv.conf" dev="nvme0n1p7" ino=5229864 > scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:net_conf_t:s0 tclass=lnk_file permissive=0 > [44558.421374] audit[37857]: AVC avc: denied { create } for pid=37857 > comm="rpmdb" scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 > tcontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tclass=udp_socket > permissive=0 > [44558.421425] audit[37857]: AVC avc: denied { create } for pid=37857 > comm="rpmdb" scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 > tcontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tclass=udp_socket > permissive=0 > [44562.278633] sudo[37855]: pam_unix(sudo:session): session closed for user > root > [44562.279075] audit[37855]: USER_END pid=37855 uid=0 auid=1000 ses=3 > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:session_close > grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix > acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/3 > res=success' > [44562.279151] audit[37855]: CRED_DISP pid=37855 uid=0 auid=1000 ses=3 > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="roo I had this problem after upgrading 29 --> 32 --> 33. Restoring SELinux context for /var/lib/rpm/Packages resolved it. *** Bug 1909525 has been marked as a duplicate of this bug. *** All denials but the one described in bz#1907408 and the scenario in bz#1901961 should be gone with updating to selinux-policy-3.14.6-32 and subsequent # restorecon -Rv /var/lib/rpm if required. Similar problem has been detected: Logged into Xfce from the greeter. hashmarkername: setroubleshoot kernel: 5.10.23-200.fc33.x86_64 package: selinux-policy-targeted-3.14.6-35.fc33.noarch reason: SELinux is preventing abrt-action-sav from 'write' accesses on the file /var/lib/rpm/rpmdb.sqlite-shm. type: libreport Similar problem has been detected: Logged into Xfce from the greeter. hashmarkername: setroubleshoot kernel: 5.10.23-200.fc33.x86_64 package: selinux-policy-targeted-3.14.6-35.fc33.noarch reason: SELinux is preventing abrt-action-sav from 'setattr' accesses on the file /var/lib/rpm/rpmdb.sqlite-shm. type: libreport I am seeing the same problem after 32->33 upgrade
#$ ls -lZ /var/lib/rpm/
total 284284
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 29777920 Jun 9 00:04 Basenames
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 32768 Jun 9 00:04 Conflictname
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0 352256 Jun 9 06:06 __db.001
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0 98304 Jun 9 06:06 __db.002
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0 1318912 Jun 9 06:06 __db.003
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 10039296 Jun 9 00:04 Dirnames
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 8192 Oct 18 2019 Enhancename
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 8192 Jun 9 00:04 Filetriggername
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 40960 Jun 9 00:04 Group
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 73728 Jun 9 00:04 Installtid
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 221184 Jun 9 00:04 Name
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 147456 Jun 9 00:04 Obsoletename
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0 242987008 Jun 9 00:04 Packages
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 3047424 Jun 9 00:04 Providename
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 28672 Jun 9 00:04 Recommendname
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 1953792 Jun 9 00:04 Requirename
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 647168 Jun 9 00:04 Sha1header
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 380928 Jun 9 00:04 Sigmd5
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 16384 Jun 9 00:04 Suggestname
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 49152 Jun 9 00:04 Supplementname
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 8192 Jun 9 00:04 Transfiletriggername
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 8192 Jun 9 00:04 Triggername
restrorecon did not help
also `systemctl status rpmdb-rebuild` gives me the following
× rpmdb-rebuild.service - RPM database rebuild
Loaded: loaded (8;;file://sumedhs.phoenix.pnq/usr/lib/systemd/system/rpmdb-rebuild.service^G/usr/lib/systemd/system/rpmdb-rebuild.service8;;^G; enabled;>
Active: failed (Result: exit-code) since Wed 2021-06-09 11:06:28 IST; 8s ago
Process: 15699 ExecStart=/usr/bin/rpmdb --rebuilddb (code=exited, status=255/EXCEPTION)
Main PID: 15699 (code=exited, status=255/EXCEPTION)
Jun 09 11:06:28 <hostname> systemd[1]: Starting RPM database rebuild...
Jun 09 11:06:28 <hostname> rpmdb[15699]: error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Permission denied)
Jun 09 11:06:28 <hostname> systemd[1]: rpmdb-rebuild.service: Main process exited, code=exited, status=255/EXCEPTION
Jun 09 11:06:28 <hostname> systemd[1]: rpmdb-rebuild.service: Failed with result 'exit-code'.
Jun 09 11:06:28 <hostname> systemd[1]: Failed to start RPM database rebuild.
My work machine is broken due to this.
Any help will be much appreciated.
I had the same problem for a couple of years (as awful as it sounds). The symptom was:
error: Unable to open sqlite database /usr/lib/sysimage/rpm/rpmdb.sqlite: unable to open database file
The work-arounds from the early comments did not work for me. I also relabeled the entire filesystem with `fixfiles -B onboot`.
I was able to get things working again with:
setenforce 0
rpmdb --rebuilddb
setenforce 1
After that I did not see the SQLite errors when attempting to cleanup/rebuild the database. I also no longer need to `setenforce 0`.
We've been fighting this on RHEL 8.4 and Centos8 Stream lately, and I cannot tell whether this is supposed to have been fixed in either release. The C8S host I'm looking at right now has selinux-policy-3.14.3-114.el8.noarch installed on it. |