Bug 1461313 - Rebuilding of rpm db set wrong SELinux context
Summary: Rebuilding of rpm db set wrong SELinux context
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 32
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1435992 1487104 1824265 1837360 1837363 1881163 1885123 1885137 1887334 1893105 1893276 1893552 1894791 1895587 1899959 1909525 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-14 07:53 UTC by Lukas Slebodnik
Modified: 2021-03-02 11:54 UTC (History)
75 users (show)

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:
Clone Of:
Environment:
Last Closed: 2020-11-25 01:42:21 UTC
Type: Bug
bcotton: fedora_prioritized_bug+


Attachments (Terms of Use)
This is a suggested patch to solve the issue. (832 bytes, patch)
2017-08-09 17:13 UTC, Villy Kruse
no flags Details | Diff

Description Lukas Slebodnik 2017-06-14 07:53:23 UTC
Description of problem:
It seems that "rpm --rebuilddb" is mention quite often these days due to libdb bug. e.g. https://www.happyassassin.net/2017/06/09/psa-rpm-database-issues-after-update-to-libdb-5-3-28-21-on-fedora-24-and-fedora-25/

However, it has a small site effect. The SELinux type is changed to "var_lib_t" instead of "rpm_var_lib_t". And it cuases a problem for SELinux troubleshooter.

Jun 14 09:32:14 host.example.com python3[13582]: detected unhandled Python exception in '/usr/sbin/setroubleshootd'

Jun 14 09:32:14 host.example.com abrt-notification[13623]: Process 13582 (setroubleshootd) of user 984 encountered an uncaught SystemExit exception



Version-Release number of selected component (if applicable):
sh$ rpm -q rpm selinux-policy
rpm-4.13.0.1-4.fc26.x86_64
selinux-policy-3.13.1-257.fc26.noarch

How reproducible:
Deterministic

Steps to Reproduce:
1. rpm --rebuilddb
2. ls -lZ /var/lib/rpm/

Actual results:
[root@host ~]# rpm --rebuilddb 
[root@host ~]# ls -lZ /var/lib/rpm/
total 95724
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0  8830976 Jun 14 09:49 Basenames
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0    16384 Jun 14 09:49 Conflictname
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0  3821568 Jun 14 09:49 Dirnames
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0     8192 Jun 14 09:49 Enhancename
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0     8192 Jun 14 09:49 Filetriggername
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0    36864 Jun 14 09:49 Group
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0    40960 Jun 14 09:49 Installtid
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0   118784 Jun 14 09:49 Name
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0    40960 Jun 14 09:49 Obsoletename
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 82808832 Jun 14 09:49 Packages
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0  1282048 Jun 14 09:49 Providename
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0     8192 Jun 14 09:49 Recommendname
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0   655360 Jun 14 09:49 Requirename
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0   192512 Jun 14 09:49 Sha1header
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0   131072 Jun 14 09:49 Sigmd5
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0     8192 Jun 14 09:49 Suggestname
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0     8192 Jun 14 09:49 Supplementname
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0     8192 Jun 14 09:49 Transfiletriggername
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0     8192 Jun 14 09:49 Triggername


Expected results:
[root@host ~]# rpm --rebuilddb
[root@host ~]# ls -lZ /var/lib/rpm/
total 95724
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0  8830976 Jun 14 09:49 Basenames
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0    16384 Jun 14 09:49 Conflictname
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0  3821568 Jun 14 09:49 Dirnames
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0     8192 Jun 14 09:49 Enhancename
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0     8192 Jun 14 09:49 Filetriggername
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0    36864 Jun 14 09:49 Group
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0    40960 Jun 14 09:49 Installtid
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0   118784 Jun 14 09:49 Name
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0    40960 Jun 14 09:49 Obsoletename
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0 82808832 Jun 14 09:49 Packages
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0  1282048 Jun 14 09:49 Providename
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0     8192 Jun 14 09:49 Recommendname
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0   655360 Jun 14 09:49 Requirename
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0   192512 Jun 14 09:49 Sha1header
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0   131072 Jun 14 09:49 Sigmd5
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0     8192 Jun 14 09:49 Suggestname
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0     8192 Jun 14 09:49 Supplementname
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0     8192 Jun 14 09:49 Transfiletriggername
-rw-r--r--. 1 root root unconfined_u:object_r:rpm_var_lib_t:s0     8192 Jun 14 09:49 Triggername

or even better
[root@host ~]# ls -lZ /var/lib/rpm/
total 95724
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0  8830976 Jun 14 09:49 Basenames
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0    16384 Jun 14 09:49 Conflictname
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0  3821568 Jun 14 09:49 Dirnames
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0     8192 Jun 14 09:49 Enhancename
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0     8192 Jun 14 09:49 Filetriggername
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0    36864 Jun 14 09:49 Group
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0    40960 Jun 14 09:49 Installtid
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0   118784 Jun 14 09:49 Name
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0    40960 Jun 14 09:49 Obsoletename
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0 82808832 Jun 14 09:49 Packages
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0  1282048 Jun 14 09:49 Providename
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0     8192 Jun 14 09:49 Recommendname
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0   655360 Jun 14 09:49 Requirename
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0   192512 Jun 14 09:49 Sha1header
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0   131072 Jun 14 09:49 Sigmd5
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0     8192 Jun 14 09:49 Suggestname
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0     8192 Jun 14 09:49 Supplementname
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0     8192 Jun 14 09:49 Transfiletriggername
-rw-r--r--. 1 root root system_u:object_r:rpm_var_lib_t:s0     8192 Jun 14 09:49 Triggername


Additional info:
[root@host ~]# matchpathcon /var/lib/rpm/*
/var/lib/rpm/Basenames  system_u:object_r:rpm_var_lib_t:s0
/var/lib/rpm/Conflictname       system_u:object_r:rpm_var_lib_t:s0
/var/lib/rpm/Dirnames   system_u:object_r:rpm_var_lib_t:s0
/var/lib/rpm/Enhancename        system_u:object_r:rpm_var_lib_t:s0
/var/lib/rpm/Filetriggername    system_u:object_r:rpm_var_lib_t:s0
/var/lib/rpm/Group      system_u:object_r:rpm_var_lib_t:s0
/var/lib/rpm/Installtid system_u:object_r:rpm_var_lib_t:s0
/var/lib/rpm/Name       system_u:object_r:rpm_var_lib_t:s0
/var/lib/rpm/Obsoletename       system_u:object_r:rpm_var_lib_t:s0
/var/lib/rpm/Packages   system_u:object_r:rpm_var_lib_t:s0
/var/lib/rpm/Providename        system_u:object_r:rpm_var_lib_t:s0
/var/lib/rpm/Recommendname      system_u:object_r:rpm_var_lib_t:s0
/var/lib/rpm/Requirename        system_u:object_r:rpm_var_lib_t:s0
/var/lib/rpm/Sha1header system_u:object_r:rpm_var_lib_t:s0
/var/lib/rpm/Sigmd5     system_u:object_r:rpm_var_lib_t:s0
/var/lib/rpm/Suggestname        system_u:object_r:rpm_var_lib_t:s0
/var/lib/rpm/Supplementname     system_u:object_r:rpm_var_lib_t:s0
/var/lib/rpm/Transfiletriggername       system_u:object_r:rpm_var_lib_t:s0
/var/lib/rpm/Triggername        system_u:object_r:rpm_var_lib_t:s0

Comment 1 Lukas Slebodnik 2017-06-14 07:55:51 UTC
Workaround is quite simple. Restore context after rebuiding rpm db

rpm --rebuilddb
restorecon -RFv /var/lib/rpm

Comment 2 Lukas Slebodnik 2017-06-14 08:08:33 UTC
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

Comment 3 Florian Festi 2017-06-14 11:35:04 UTC
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...

Comment 4 Lukas Slebodnik 2017-06-15 14:59:17 UTC
Lukas,

Coudl you (or sb else from SELinux team) help  Florian to fix it?

Comment 5 Florian Festi 2017-06-29 08:25:55 UTC
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.

Comment 6 Lukas Slebodnik 2017-07-04 07:29:58 UTC
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.

Comment 7 Lukas Vrabec 2017-07-04 09:54:58 UTC
*** Bug 1435992 has been marked as a duplicate of this bug. ***

Comment 8 Lukas Slebodnik 2017-07-04 10:24:09 UTC
Adam,

Could you update your blog post? (for now)
https://fedoramagazine.org/psa-errors-updating-libdb/

Comment 9 Adam Williamson 2017-07-17 23:18:19 UTC
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.

Comment 10 Adam Williamson 2017-07-19 01:31:40 UTC
I've now edited the blog post, and also the Common Bugs entries that mention the rebuilding the database.

Comment 11 Lukas Slebodnik 2017-07-19 07:47:14 UTC
Adding back needinfo to LukasV @see comment4

Comment 12 Villy Kruse 2017-08-02 14:55:51 UTC
(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.

Comment 13 Villy Kruse 2017-08-09 17:13:17 UTC
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

Comment 14 Lukas Slebodnik 2017-08-12 19:23:51 UTC
(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)

Comment 15 Villy Kruse 2017-08-13 12:02:15 UTC
(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@redhat.com>
Date:   Wed May 10 09:17:20 2017 +0300

Comment 16 Villy Kruse 2017-08-13 19:25:27 UTC
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

Comment 17 Lukas Slebodnik 2017-08-14 08:49:10 UTC
(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@redhat.com>
> 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

Comment 18 Lukas Vrabec 2017-08-14 10:21:54 UTC
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.

Comment 19 Villy Kruse 2017-08-14 11:36:07 UTC
(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@redhat.com>  2017-06-29 09:08:32
Committer: Florian Festi <ffesti@redhat.com>  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.

Comment 20 Igor Gnatenko 2017-08-31 09:27:14 UTC
*** Bug 1487104 has been marked as a duplicate of this bug. ***

Comment 21 Villy Kruse 2017-10-08 10:33:37 UTC
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.

Comment 22 Panu Matilainen 2017-12-08 13:20:02 UTC
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.

Comment 23 Fedora Update System 2018-03-12 18:28:05 UTC
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

Comment 24 Fedora Update System 2018-03-13 23:56:36 UTC
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

Comment 25 Fedora Update System 2018-03-20 17:32:09 UTC
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.

Comment 26 Villy Kruse 2018-03-20 20:52:54 UTC
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

Comment 27 Henry Kroll 2020-02-22 07:20:24 UTC
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.

Comment 28 Villy Kruse 2020-02-22 09:03:48 UTC
(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.

Comment 29 Panu Matilainen 2020-04-16 05:47:55 UTC
Reopening as the fix in F26 apparently never really fixed the issue, this has been reported occasionally all along the way.

Comment 30 Panu Matilainen 2020-04-16 05:54:46 UTC
*** Bug 1824265 has been marked as a duplicate of this bug. ***

Comment 31 Villy Kruse 2020-05-06 14:05:46 UTC
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.

Comment 32 Zdenek Pytela 2020-05-06 14:39:23 UTC
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?

Comment 33 Villy Kruse 2020-05-06 15:41:14 UTC
(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)


.

Comment 34 Zdenek Pytela 2020-05-19 11:01:31 UTC
*** Bug 1837363 has been marked as a duplicate of this bug. ***

Comment 35 Zdenek Pytela 2020-05-27 15:28:36 UTC
*** Bug 1837360 has been marked as a duplicate of this bug. ***

Comment 36 Zdenek Pytela 2020-05-27 16:40:35 UTC
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;

Comment 37 Villy Kruse 2020-05-27 17:10:57 UTC
(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.

Comment 38 Panu Matilainen 2020-05-28 06:22:30 UTC
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.

Comment 39 Villy Kruse 2020-05-28 07:16:04 UTC
(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.

Comment 40 Panu Matilainen 2020-05-28 08:08:01 UTC
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.

Comment 41 Zdenek Pytela 2020-05-28 11:01:25 UTC
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.

Comment 42 Villy Kruse 2020-05-28 12:48:25 UTC
(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.

Comment 43 Villy Kruse 2020-05-28 13:06:20 UTC
(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.

Comment 44 Adam Williamson 2020-06-30 19:47:16 UTC
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.

Comment 45 Villy Kruse 2020-07-01 04:51:48 UTC
(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.

Comment 46 Villy Kruse 2020-08-02 06:59:58 UTC
Excuse me for asking:  Is there any progress on this issue?

Comment 47 Panu Matilainen 2020-08-03 07:30:00 UTC
(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)

Comment 48 Villy Kruse 2020-08-03 10:01:04 UTC
(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.

Comment 49 Stefan Becker 2020-10-22 06:53:58 UTC
*** Bug 1881163 has been marked as a duplicate of this bug. ***

Comment 50 Miro Hrončok 2020-10-24 18:32:15 UTC
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`?

Comment 51 Villy Kruse 2020-10-24 20:23:45 UTC
(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.

Comment 52 Miro Hrončok 2020-10-24 22:03:43 UTC
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).

Comment 53 Kostya Vasilyev 2020-10-28 06:50:32 UTC
> 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.

Comment 54 James Allen 2020-10-30 04:07:35 UTC
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.

Comment 55 Panu Matilainen 2020-10-30 07:13:19 UTC
(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.

Comment 56 Zdenek Pytela 2020-10-30 09:06:53 UTC
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.

Comment 57 Zdenek Pytela 2020-10-30 09:08:15 UTC
*** Bug 1893105 has been marked as a duplicate of this bug. ***

Comment 58 Villy Kruse 2020-10-30 14:25:08 UTC
(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.

Comment 59 Zdenek Pytela 2020-10-30 17:20:01 UTC
*** Bug 1893276 has been marked as a duplicate of this bug. ***

Comment 60 Chris Murphy 2020-11-02 04:01:37 UTC
Related and possible dups: bug 1885137, bug 1885123, bug 1893552.

Comment 61 Zdenek Pytela 2020-11-02 07:39:37 UTC
*** Bug 1893552 has been marked as a duplicate of this bug. ***

Comment 62 Zdenek Pytela 2020-11-02 08:00:29 UTC
*** Bug 1885123 has been marked as a duplicate of this bug. ***

Comment 63 Zdenek Pytela 2020-11-02 08:00:46 UTC
*** Bug 1885137 has been marked as a duplicate of this bug. ***

Comment 64 Zdenek Pytela 2020-11-02 18:08:27 UTC
*** Bug 1893552 has been marked as a duplicate of this bug. ***

Comment 65 thedatum+bz 2020-11-03 03:20:50 UTC
Same issue on two systems upgraded from F32 to F33. `restorecon -RFv /var/lib/rpm` appears to fix it.

Comment 66 Zdenek Pytela 2020-11-03 20:26:15 UTC
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?

Comment 68 Zdenek Pytela 2020-11-04 14:51:42 UTC
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

Comment 69 Ben Cotton 2020-11-04 18:24:00 UTC
Accepted as a Fedora Prioritized Bug

Comment 70 Panu Matilainen 2020-11-05 07:04:17 UTC
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.

Comment 71 Villy Kruse 2020-11-05 08:29:50 UTC
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

Comment 72 Zdenek Pytela 2020-11-06 18:17:21 UTC
(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.

Comment 73 Panu Matilainen 2020-11-09 06:57:55 UTC
> 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.

Comment 74 Panu Matilainen 2020-11-09 07:27:26 UTC
*** Bug 1895587 has been marked as a duplicate of this bug. ***

Comment 75 Fedora Update System 2020-11-09 18:46:06 UTC
FEDORA-2020-77b49aa207 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-77b49aa207

Comment 76 Fedora Update System 2020-11-10 02:20:34 UTC
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.

Comment 77 Zdenek Pytela 2020-11-10 15:56:56 UTC
*** Bug 1894791 has been marked as a duplicate of this bug. ***

Comment 78 Hin-Tak Leung 2020-11-10 23:04:49 UTC
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

Comment 79 Samuel Sieb 2020-11-10 23:16:20 UTC
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.

Comment 80 Villy Kruse 2020-11-12 06:39:56 UTC
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.

Comment 81 W. de Heiden 2020-11-12 14:23:58 UTC
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!

Comment 82 Daniel Demus 2020-11-14 08:44:03 UTC
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

Comment 83 Tony 2020-11-15 18:38:01 UTC
(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]#

Comment 84 Villy Kruse 2020-11-15 20:18:17 UTC
(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?

Comment 85 Tony 2020-11-15 20:37:18 UTC
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.

Comment 86 Villy Kruse 2020-11-15 20:53:56 UTC
(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.

Comment 87 Tony 2020-11-15 20:56:29 UTC
(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!

Comment 88 Tony 2020-11-15 21:03:47 UTC
(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.

Comment 89 Tony 2020-11-15 21:34:16 UTC
(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

Comment 90 Villy Kruse 2020-11-16 06:17:10 UTC
(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

Comment 91 Panu Matilainen 2020-11-16 07:24:29 UTC
(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.

Comment 92 Zdenek Pytela 2020-11-16 08:59:27 UTC
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.

Comment 93 Villy Kruse 2020-11-16 10:30:38 UTC
(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.

Comment 94 Villy Kruse 2020-11-16 10:37:07 UTC
(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.

Comment 95 Panu Matilainen 2020-11-16 10:52:35 UTC
> 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.

Comment 96 Daniel Demus 2020-11-20 13:14:09 UTC
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

Comment 97 Zdenek Pytela 2020-11-20 13:57:24 UTC
*** Bug 1899959 has been marked as a duplicate of this bug. ***

Comment 98 Neal Becker 2020-11-20 15:57:59 UTC
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

Comment 99 michael 2020-11-25 00:35:11 UTC
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

Comment 100 Fedora Update System 2020-11-25 01:42:21 UTC
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.

Comment 101 Zdenek Pytela 2020-11-25 16:11:44 UTC
*** Bug 1887334 has been marked as a duplicate of this bug. ***

Comment 102 Pressluft 2020-11-26 09:43:56 UTC
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

Comment 103 Zdenek Pytela 2020-11-26 10:14:22 UTC
(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

Comment 104 Pressluft 2020-11-26 10:21:00 UTC
(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!!!

Comment 105 Nick Coghlan 2020-12-05 06:34:51 UTC
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
========

Comment 106 Chris Murphy 2020-12-05 09:00:21 UTC
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

Comment 107 David Abdurachmanov 2020-12-05 14:39:31 UTC
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.

Comment 108 Nikita Goncharuk 2020-12-10 18:46:01 UTC
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

Comment 109 Nikita Goncharuk 2020-12-10 18:46:49 UTC
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

Comment 110 Lukas Slebodnik 2020-12-16 14:48:12 UTC
(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.

Comment 111 Zdenek Pytela 2020-12-16 18:39:08 UTC
> > 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.

Comment 112 Konstantin Kolinko 2020-12-25 16:35:23 UTC
(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

Comment 113 Villy Kruse 2020-12-25 18:31:34 UTC
(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.

Comment 114 Prarit Bhargava 2020-12-26 00:17:50 UTC
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

Comment 115 Krause.Markus 2020-12-28 19:51:44 UTC
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.

Comment 116 Chris Murphy 2020-12-29 07:59:26 UTC
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

Comment 117 Villy Kruse 2020-12-29 08:55:22 UTC
(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

Comment 118 jjj 2021-01-02 22:40:27 UTC
I had this problem after upgrading 29 --> 32 --> 33. Restoring SELinux context for /var/lib/rpm/Packages resolved it.

Comment 119 Zdenek Pytela 2021-01-04 12:06:12 UTC
*** Bug 1909525 has been marked as a duplicate of this bug. ***

Comment 120 Zdenek Pytela 2021-01-04 12:25:22 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.