Description of problem: rpm --initdb silently fails, no db is created. I'm attempting to build qubes-os on Fedora but it fails initalizing the rpm databae. Version-Release number of selected component (if applicable): Fedora 33: rpm 4.16.0-5.fc33 Fedora 32: rpm 4.15.1-3.fc32.1 How reproducible: Follow example here: https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch04s05s03.html Steps to Reproduce: 1. mkdir /tmp/rpm 2. rpm --initdb --dbpath /tmp/rpm 3. echo $? 4. ls /tmp/rpm Actual results: rpm exit code is 255 and /tmp/rpm is empty Expected results: A new rpm databased should be in /tmp/rpm Additional info:
The new selinux-policy is preventing both rpmdb from initializing a database in an arbitrary location and also from logging an error about it.
After removing the dontaudit rules, the Steps to Reproduce lead to several SELinux denials which will be attached. Here is a summary from audit2allow: #============= rpmdb_t ============== allow rpmdb_t net_conf_t:file { getattr open }; allow rpmdb_t nscd_var_run_t:dir search; allow rpmdb_t passwd_file_t:file open; allow rpmdb_t self:capability net_admin; allow rpmdb_t sssd_var_lib_t:dir search; allow rpmdb_t system_dbusd_var_run_t:dir search; #!!!! This avc can be allowed using the boolean 'daemons_use_tty' allow rpmdb_t user_devpts_t:chr_file { read write }; allow rpmdb_t user_tmp_t:dir { getattr search };
Created attachment 1738148 [details] SELinux denials which appeared in enforcing mode
Created attachment 1738149 [details] SELinux denials which appeared in permissive mode
The first half of that, ie the name services and network part, can (continue to) be ignored/denied. rpmdb doesn't actually need them for anything and in fact they should be gone entirely in rpm >= 4.16.1 when released.
Thanks everyone. As this is a selinux issue, I'm able to continue to build qubes-os by using a boxes vm with `sudo setenforce 0` to work around selinux causing rpm to fail. Dropping the priority to medium. Thanks for the quick response.
*** This bug has been marked as a duplicate of bug 1901961 ***