+++ This bug was initially created as a clone of Bug #1461313 +++

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

--- Additional comment from Lukas Slebodnik on 2017-06-14 07:55:51 UTC ---

Workaround is quite simple. Restore context after rebuiding rpm db

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

--- Additional comment from Lukas Slebodnik on 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

--- Additional comment from Florian Festi on 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...

--- Additional comment from Lukas Slebodnik on 2017-06-15 14:59:17 UTC ---

Lukas,

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

--- Additional comment from Florian Festi on 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.

--- Additional comment from Lukas Slebodnik on 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.

--- Additional comment from Lukas Vrabec on 2017-07-04 09:54:58 UTC ---



--- Additional comment from Lukas Slebodnik on 2017-07-04 10:24:09 UTC ---

Adam,

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

--- Additional comment from Adam Williamson on 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.

--- Additional comment from Adam Williamson on 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.

--- Additional comment from Lukas Slebodnik on 2017-07-19 07:47:14 UTC ---

Adding back needinfo to LukasV @see comment4

--- Additional comment from Villy Kruse on 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.

--- Additional comment from Villy Kruse on 2017-08-09 17:13:17 UTC ---

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

--- Additional comment from Lukas Slebodnik on 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)

--- Additional comment from Villy Kruse on 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>
Date:   Wed May 10 09:17:20 2017 +0300

--- Additional comment from Villy Kruse on 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

--- Additional comment from Lukas Slebodnik on 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>
> 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

--- Additional comment from Lukas Vrabec on 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.

--- Additional comment from Villy Kruse on 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>  2017-06-29 09:08:32
Committer: Florian Festi <ffesti>  2017-07-30 11:06:47
Parent: 98efb7f6dc222ed175516298a34e807053d125f4 (reference proper debug files whenever RemovePathPostfixes is used)
Child:  4b0356c5671daafb954c8ee932742ad7da57f345 (Set permissions and owner for new database to the old values)
Branches: master, remotes/origin/master, remotes/origin/rpm-4.14.x
Follows: rpm-4.13.0-alpha
Precedes:

    Replace whole rpmdb directory on rebuilddb instead of moving around files

    This fixes issues with rebuilding the database for another backend which before could leave behind files from the old format.

------
/var/lib/rpmrebuilddb.*(/.*)?  is there already, but has no effect until you
run restorecon.

--- Additional comment from Igor Gnatenko on 2017-08-31 09:27:14 UTC ---



--- Additional comment from Villy Kruse on 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.

--- Additional comment from Panu Matilainen on 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.

--- Additional comment from Fedora Update System on 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

--- Additional comment from Fedora Update System on 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

--- Additional comment from Fedora Update System on 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.

--- Additional comment from Villy Kruse on 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

--- Additional comment from Henry Kroll on 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.

--- Additional comment from Villy Kruse on 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.

--- Additional comment from Panu Matilainen on 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.

--- Additional comment from Panu Matilainen on 2020-04-16 05:54:46 UTC ---



--- Additional comment from Villy Kruse on 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.

--- Additional comment from Zdenek Pytela on 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?

--- Additional comment from Villy Kruse on 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)


.

--- Additional comment from Zdenek Pytela on 2020-05-19 11:01:31 UTC ---



--- Additional comment from Zdenek Pytela on 2020-05-27 15:28:36 UTC ---



--- Additional comment from Zdenek Pytela on 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;

--- Additional comment from Villy Kruse on 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.

--- Additional comment from Panu Matilainen on 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.

--- Additional comment from Villy Kruse on 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.

--- Additional comment from Panu Matilainen on 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.

--- Additional comment from Zdenek Pytela on 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.

--- Additional comment from Villy Kruse on 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.

--- Additional comment from Villy Kruse on 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.

--- Additional comment from Adam Williamson on 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.

--- Additional comment from Villy Kruse on 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.

--- Additional comment from Villy Kruse on 2020-08-02 06:59:58 UTC ---

Excuse me for asking:  Is there any progress on this issue?

--- Additional comment from Panu Matilainen on 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)

--- Additional comment from Villy Kruse on 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.

--- Additional comment from Stefan Becker on 2020-10-22 06:53:58 UTC ---



--- Additional comment from Miro Hrončok on 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`?

--- Additional comment from Villy Kruse on 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.

--- Additional comment from Miro Hrončok on 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).

--- Additional comment from Kostya Vasilyev on 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.

--- Additional comment from James Allen on 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.

--- Additional comment from Panu Matilainen on 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.

--- Additional comment from Zdenek Pytela on 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.

--- Additional comment from Zdenek Pytela on 2020-10-30 09:08:15 UTC ---



--- Additional comment from Villy Kruse on 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.

--- Additional comment from Zdenek Pytela on 2020-10-30 17:20:01 UTC ---



--- Additional comment from Chris Murphy on 2020-11-02 04:01:37 UTC ---

Related and possible dups: bug 1885137, bug 1885123, bug 1893552.

--- Additional comment from Zdenek Pytela on 2020-11-02 07:39:37 UTC ---



--- Additional comment from Zdenek Pytela on 2020-11-02 08:00:29 UTC ---



--- Additional comment from Zdenek Pytela on 2020-11-02 08:00:46 UTC ---



--- Additional comment from Zdenek Pytela on 2020-11-02 18:08:27 UTC ---



--- Additional comment from  on 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.

--- Additional comment from Zdenek Pytela on 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?

--- Additional comment from Zdenek Pytela on 2020-11-03 21:12:45 UTC ---

Here is an F33 scratchbuild:
https://koji.fedoraproject.org/koji/taskinfo?taskID=54873612

PRs:
https://github.com/fedora-selinux/selinux-policy/pull/471
https://github.com/fedora-selinux/selinux-policy-contrib/pull/358

--- Additional comment from Zdenek Pytela on 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

--- Additional comment from Ben Cotton on 2020-11-04 18:24:00 UTC ---

Accepted as a Fedora Prioritized Bug

--- Additional comment from Panu Matilainen on 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.

--- Additional comment from Villy Kruse on 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

--- Additional comment from Zdenek Pytela on 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.

--- Additional comment from Panu Matilainen on 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.

--- Additional comment from Panu Matilainen on 2020-11-09 07:27:26 UTC ---



--- Additional comment from Fedora Update System on 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

--- Additional comment from Fedora Update System on 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.

--- Additional comment from Zdenek Pytela on 2020-11-10 15:56:56 UTC ---



--- Additional comment from Hin-Tak Leung on 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

--- Additional comment from Samuel Sieb on 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.

--- Additional comment from Villy Kruse on 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.

--- Additional comment from W. de Heiden on 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!

--- Additional comment from Daniel Demus on 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

--- Additional comment from Tony on 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]#

--- Additional comment from Villy Kruse on 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?

--- Additional comment from Tony on 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.

--- Additional comment from Villy Kruse on 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.

--- Additional comment from Tony on 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!

--- Additional comment from Tony on 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.