Description of problem: I've just ran mock with my custom configuration stored in the /etc/mock/ directory. SELinux is preventing systemd-machine from 'read' accesses on the directory /var/lib/mock/anaconda-rawhide-x86_64/root. ***** Plugin restorecon (99.5 confidence) suggests ************************ If you want to fix the label. /var/lib/mock/anaconda-rawhide-x86_64/root default label should be mock_var_lib_t. Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly. Do # /sbin/restorecon -v /var/lib/mock/anaconda-rawhide-x86_64/root ***** Plugin catchall (1.49 confidence) suggests ************************** If you believe that systemd-machine should be allowed read access on the root directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'systemd-machine' --raw | audit2allow -M my-systemdmachine # semodule -X 300 -i my-systemdmachine.pp Additional Information: Source Context system_u:system_r:systemd_machined_t:s0 Target Context unconfined_u:object_r:user_tmp_t:s0 Target Objects /var/lib/mock/anaconda-rawhide-x86_64/root [ dir ] Source systemd-machine Source Path systemd-machine Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.3-43.fc30.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.2.9-200.fc30.x86_64 #1 SMP Fri Aug 16 21:37:45 UTC 2019 x86_64 x86_64 Alert Count 25 First Seen 2019-07-17 14:12:15 CEST Last Seen 2019-09-02 14:41:39 CEST Local ID 5c3c38b9-9bed-4c06-b3cb-ca9379cea3c6 Raw Audit Messages type=AVC msg=audit(1567428099.852:757): avc: denied { read } for pid=1448 comm="systemd-machine" name="/" dev="tmpfs" ino=1070316 scontext=system_u:system_r:systemd_machined_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=dir permissive=0 Hash: systemd-machine,systemd_machined_t,user_tmp_t,dir,read Version-Release number of selected component: selinux-policy-3.14.3-43.fc30.noarch Additional info: component: selinux-policy reporter: libreport-2.10.1 hashmarkername: setroubleshoot kernel: 5.2.9-200.fc30.x86_64 type: libreport
I forgot to say that the mock command is run as normal user in a mock group.
Also I'm using tmpfs plugin. If you want I can try this without the plugin.
Hi Jiri, Yes please, try it without all the plugins and attach please reproducer. Thanks, Lukas.
I'm able to reproduce this with parallel running of two mocks with our script for tests. Most probably this is happening when there are two --chroot commands parallel but I wasn't able to create a minimal reproducer yet. I'll try to create the reproducer.
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
Jiri, Did you manage to create the reproducer to trigger the issue?
Yes, sorry for taking me so long. With a new mock-2.1-1 you can reproduce this by following these steps: 1) Enable tmpfs by creating ~/.config/mock.cfg with line: config_opts['plugin_conf']['tmpfs_enable'] = True 1) mock -r fedora-rawhide-x86_64 --scrub all # to clean everything you may have from before 2) mock -r fedora-rawhide-x86_64 --init # initialize, this will download packages and set caches 3) mock -r fedora-rawhide-x86_64 -i gnome-shell # start downloading any package 4) Press CTRL+C during the repo metadata download or later during the installation To reproduce the error second time it's enough to just go step 3 and 4. This is happening only with tmpfs plugin enabled.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. 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 Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Not an issue for me anymore. It seems harmless and we are moving most of our use-cases away from mock.
Thanks for letting us know.