Description of problem: The new rpmdb-related policy turns out to be overly strict... Version-Release number of selected component (if applicable): selinux-policy-targeted-3.14.6-30.fc33 How reproducible: Always Steps to Reproduce: 1. rm -rf /srv/test/* 2. rpmdb --root /srv/test --initdb; echo $? 3. ls /srv/test/ Actual results: rpmdb returns with error code, no db is created # ls /srv/test/ # Expected results: rpmdb returns with 0, db is created: # ls /srv/test/var/lib/rpm/ rpmdb.sqlite rpmdb.sqlite-shm rpmdb.sqlite-wal Additional info: This was known of course (https://bugzilla.redhat.com/show_bug.cgi?id=1461313#c70) but at that time it didn't seem that relevant. Turns out ability to create databases at funny locations is more important than initially thought... There's are no fire burning anywhere because of this right now, but it's something that needs sorting out before too long (say, in time for F34 preferably).
Panu, While not a priority, I'd like to see all common scenarios working. I would expect though sequence like this: # rm -rf /srv/test # mkdir -p /srv/test/var/lib/rpm # semanage fcontext -a -e / /srv/test # restorecon -Rv /srv/test Relabeled /srv/test from unconfined_u:object_r:var_t:s0 to unconfined_u:object_r:root_t:s0 Relabeled /srv/test/var/lib from unconfined_u:object_r:var_t:s0 to unconfined_u:object_r:var_lib_t:s0 Relabeled /srv/test/var/lib/rpm from unconfined_u:object_r:var_t:s0 to unconfined_u:object_r:rpm_var_lib_t:s0 # rpmdb --root /srv/test --initdb; echo $? 0 # ls -Za /srv/test/var/lib/rpm/ unconfined_u:object_r:rpm_var_lib_t:s0 . unconfined_u:object_r:var_lib_t:s0 .. unconfined_u:object_r:rpm_var_lib_t:s0 rpmdb.sqlite unconfined_u:object_r:rpm_var_lib_t:s0 rpmdb.sqlite-shm unconfined_u:object_r:rpm_var_lib_t:s0 rpmdb.sqlite-wal In which situation would you initialize rpm database in an empty root-like directory? Initializing rpm db in an empty dir is definitely something we did not test.
It's not an "end user" thing generally, but something tools like mock might want to do so, especially in the future as rpm wont create a new database by just querying one. And probably various chroot scenarios including rescue-scenarios etc. A more immediate problem is that the new policy appears to prevent rpmdb from outputting errors at all. In the above, it just silently but if you strace the process it actually tries to log an error: [...] write(2, "error: ", 7) = 7 write(2, "can't create transaction lock on"..., 93) = 93 ioctl(0, TCGETS, 0x7ffe758bdea0) = -1 ENOTTY (Inappropriate ioctl for device) exit_group(-1) = ? +++ exited with 255 +++ This is peculiar as the writes seem to succeed yet nothing is actually outputted. A simpler case to demo this: [root@lumikko ~]# rpmdb --invalid [root@lumikko ~]# setenforce 0 [root@lumikko ~]# rpmdb --invalid rpmdb: --invalid: unknown option [root@lumikko ~]#
(In reply to Panu Matilainen from comment #2) > It's not an "end user" thing generally, but something tools like mock might > want to do so, especially in the future as rpm wont create a new database by > just querying one. And probably various chroot scenarios including > rescue-scenarios etc. Panu, I would like to see some scenario first before suggesting another change in the policy. Is there already an outline of the near future behaviour and planned changes? > > A more immediate problem is that the new policy appears to prevent rpmdb > from outputting errors at all. In the above, it just silently but if you > strace the process it actually tries to log an error: > > [...] > write(2, "error: ", 7) = 7 > write(2, "can't create transaction lock on"..., 93) = 93 > ioctl(0, TCGETS, 0x7ffe758bdea0) = -1 ENOTTY (Inappropriate ioctl for > device) > exit_group(-1) = ? > +++ exited with 255 +++ > > This is peculiar as the writes seem to succeed yet nothing is actually > outputted. A simpler case to demo this: > [root@lumikko ~]# rpmdb --invalid > [root@lumikko ~]# setenforce 0 > [root@lumikko ~]# rpmdb --invalid > rpmdb: --invalid: unknown option > [root@lumikko ~]# The second problem has been fixed in rawhide and will be a part of the next F33 build, see bz#1899548.
> I would like to see some scenario first before suggesting another change in the policy. > Is there already an outline of the near future behaviour and planned changes? One usage scenario is in bug 1906289. That sort of thing will become more relevant in the future. As of 4.16 even 'rpm -qa --root /foo' will initialize an empty database at /foo/var/lib/rpm but that's not going to be the case with >= 4.17. I hope we wont need an explicit 'rpmdb --initdb' before every chroot installation but there are situations where you explicitly want to start with an empty rpmdb at a rather arbitrary location.
Marking bz#1906289 a dup and copy-pasting: === 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 ===
*** Bug 1906289 has been marked as a duplicate of this bug. ***
(In reply to Zdenek Pytela from comment #5) > Marking bz#1906289 a dup and copy-pasting: > > === > 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 > === You should label the parent directory of the new rpm directory the same was as /var/lib. Then it works properly.
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
Panu, Is this still a problem which needs to be resolved? I am afraid that a really general scenario needs to be addressed in the rpm package, selinux-policy can be of very little help here.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days