The openQA default-install-and-boot test for the Atomic Host installer image is showing several instances of one SELinux denial immediately after boot: type=AVC msg=audit(1497548408.952:169): avc: denied { execute } for pid=998 comm="nm-dispatcher" name="10-ifcfg-rh-routes.sh" dev="dm-0" ino=28911 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:NetworkManager_etc_t:s0 tclass=file permissive=0 with each occurrence the pid of the nm-dispatcher process changes, so it seems like perhaps this denial causes the operation (whatever exactly nm-dispatcher is doing, I'm not sure) to fail and then it is immediately retried, hits the denial, and fails again. This doesn't seem to prevent networking from working. This seems to have started happening between Fedora-26-20170605.n.0 (which would have been effectively identical to Beta) and Fedora-26-20170611.n.1 (which was the first successful post-Beta-freeze compose, with all the packages queued for stable during the Beta freeze included).
Created attachment 1288165 [details] more selinux denials
The denials in that attachment are from an atomic host vagrant box (i.e. not just the installer, but the installed system).
[root@vanilla-f26atomic ~]# rpm-ostree status State: idle Deployments: ● fedora-atomic:fedora/26/x86_64/atomic-host Version: 26.59 (2017-06-12 02:00:29) Commit: 95283eba36118de8b065ca29c079760cc82394e0128aadf8f32bb867454b64fb [root@vanilla-f26atomic ~]# [root@vanilla-f26atomic ~]# [root@vanilla-f26atomic ~]# rpm -q selinux-policy selinux-policy-3.13.1-254.fc26.noarch [root@vanilla-f26atomic ~]# rpm -q kernel kernel-4.11.0-2.fc26.x86_64 [root@vanilla-f26atomic ~]# rpm -q NetworkManager NetworkManager-1.8.0-4.fc26.x86_64
also seeing on a host with newer versions: ``` [root@f26-updates-testing ~]# rpm -q selinux-policy NetworkManager kernel selinux-policy-3.13.1-257.fc26.noarch NetworkManager-1.8.0-5.fc26.x86_64 kernel-4.11.4-300.fc26.x86_64 ```
Looks like 10-ifcfg-rh-routes.sh has the wrong type on it, it is labeled as a netoworkmanager config file instead of an executable.
What is the path to 10-ifcfg-rh-routes.sh matchpathcon /etc/NetworkManager/dispatcher.d/10-ifcfg-rh-routes.sh /etc/NetworkManager/dispatcher.d/10-ifcfg-rh-routes.sh system_u:object_r:NetworkManager_initrc_exec_t:s0 restorecon -R -v /etc/NetworkManager Should fix the label.
``` [root@vanilla-f26atomic ~]# ls -lZ /etc/NetworkManager/dispatcher.d/* -rwxr-xr-x. 1 root root system_u:object_r:NetworkManager_etc_t:s0 175 Jun 12 02:37 /etc/NetworkManager/dispatcher.d/00-netreport -rwxr-xr-x. 1 root root system_u:object_r:NetworkManager_etc_t:s0 100 Jun 12 02:37 /etc/NetworkManager/dispatcher.d/04-iscsi -rwxr-xr-x. 1 root root system_u:object_r:NetworkManager_etc_t:s0 1056 Jun 12 02:37 /etc/NetworkManager/dispatcher.d/10-ifcfg-rh-routes.sh -rwxr-xr-x. 1 root root system_u:object_r:NetworkManager_etc_t:s0 933 Jun 12 02:37 /etc/NetworkManager/dispatcher.d/11-dhclient -rwxr-xr-x. 1 root root system_u:object_r:NetworkManager_etc_t:s0 436 Jun 12 02:37 /etc/NetworkManager/dispatcher.d/20-chrony -rwxr-xr-x. 1 root root system_u:object_r:NetworkManager_etc_t:s0 719 Jun 12 02:37 /etc/NetworkManager/dispatcher.d/hook-network-manager /etc/NetworkManager/dispatcher.d/no-wait.d: total 0 lrwxrwxrwx. 1 root root system_u:object_r:NetworkManager_etc_t:s0 24 Jun 12 02:37 10-ifcfg-rh-routes.sh -> ../10-ifcfg-rh-routes.sh /etc/NetworkManager/dispatcher.d/pre-down.d: total 0 /etc/NetworkManager/dispatcher.d/pre-up.d: total 0 lrwxrwxrwx. 1 root root system_u:object_r:NetworkManager_etc_t:s0 34 Jun 12 02:37 10-ifcfg-rh-routes.sh -> ../no-wait.d/10-ifcfg-rh-routes.sh [root@vanilla-f26atomic ~]# ls -lZ /etc/NetworkManager/dispatcher.d/10-ifcfg-rh-routes.sh -rwxr-xr-x. 1 root root system_u:object_r:NetworkManager_etc_t:s0 1056 Jun 12 02:37 /etc/NetworkManager/dispatcher.d/10-ifcfg-rh-routes.sh ```
Did restorecon fix the labels?
``` [root@vanilla-f26atomic ~]# restorecon -R -v /etc/NetworkManager Relabeled /etc/NetworkManager/dispatcher.d from system_u:object_r:NetworkManager_etc_t:s0 to system_u:object_r:NetworkManager_initrc_exec_t:s0 Relabeled /etc/NetworkManager/dispatcher.d/00-netreport from system_u:object_r:NetworkManager_etc_t:s0 to system_u:object_r:NetworkManager_initrc_exec_t:s0 Relabeled /etc/NetworkManager/dispatcher.d/04-iscsi from system_u:object_r:NetworkManager_etc_t:s0 to system_u:object_r:NetworkManager_initrc_exec_t:s0 Relabeled /etc/NetworkManager/dispatcher.d/10-ifcfg-rh-routes.sh from system_u:object_r:NetworkManager_etc_t:s0 to system_u:object_r:NetworkManager_initrc_exec_t:s0 Relabeled /etc/NetworkManager/dispatcher.d/11-dhclient from system_u:object_r:NetworkManager_etc_t:s0 to system_u:object_r:NetworkManager_initrc_exec_t:s0 Relabeled /etc/NetworkManager/dispatcher.d/20-chrony from system_u:object_r:NetworkManager_etc_t:s0 to system_u:object_r:NetworkManager_initrc_exec_t:s0 Relabeled /etc/NetworkManager/dispatcher.d/hook-network-manager from system_u:object_r:NetworkManager_etc_t:s0 to system_u:object_r:NetworkManager_initrc_exec_t:s0 Relabeled /etc/NetworkManager/dispatcher.d/no-wait.d from system_u:object_r:NetworkManager_etc_t:s0 to system_u:object_r:NetworkManager_initrc_exec_t:s0 Relabeled /etc/NetworkManager/dispatcher.d/no-wait.d/10-ifcfg-rh-routes.sh from system_u:object_r:NetworkManager_etc_t:s0 to system_u:object_r:NetworkManager_initrc_exec_t:s0 Relabeled /etc/NetworkManager/dispatcher.d/pre-down.d from system_u:object_r:NetworkManager_etc_t:s0 to system_u:object_r:NetworkManager_initrc_exec_t:s0 Relabeled /etc/NetworkManager/dispatcher.d/pre-up.d from system_u:object_r:NetworkManager_etc_t:s0 to system_u:object_r:NetworkManager_initrc_exec_t:s0 Relabeled /etc/NetworkManager/dispatcher.d/pre-up.d/10-ifcfg-rh-routes.sh from system_u:object_r:NetworkManager_etc_t:s0 to system_u:object_r:NetworkManager_initrc_exec_t:s0 Relabeled /etc/NetworkManager/system-connections from system_u:object_r:NetworkManager_etc_t:s0 to system_u:object_r:NetworkManager_etc_rw_t:s0 ```
This might be a regression from https://github.com/ostreedev/ostree/pull/797 `restorecon -nvR /etc/` shows a lot of diffs.
This reproduces in F25AH too, starting from: ``` fedora-atomic:fedora-atomic/25/x86_64/docker-host Version: 25.137 (2017-06-04 23:31:40) Commit: 0ed61d7441eddf96e6a98de4f10f4675268c7888b6d2b8a405b8c21fe6c92d23 ``` Then ``` $ rpm-ostree deploy 25.136 $ systemctl reboot ... $ restorecon -nvR /etc ```
is there a specific test we can add for this to the atomic-host-tests suite?
https://github.com/ostreedev/ostree/pull/936 There's an installed test case there - which gets back to https://github.com/projectatomic/atomic-host-tests/issues/74
ostree-2017.7-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-7b464a11e7
ostree-2017.7-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-d194990d45
I don't think this actually affects F25AH. The commit [1] from the #797 PR you linked to #797 only made it into 2017.6, which wasn't in F25. ``` $ koji latest-build f25-updates ostree Build Tag Built by ---------------------------------------- -------------------- ---------------- ostree-2017.6-2.fc25 f25-updates walters ``` Also here is what I see from today's the cloud image [2] ``` [root@cloudhost ~]# restorecon -vnR /etc/ restorecon reset /etc/sysconfig/anaconda context system_u:object_r:etc_runtime_t:s0->system_u:object_r:etc_t:s0 ``` [1] https://github.com/ostreedev/ostree/commit/e8efd1c8dcaad8fbd3b05c400972d237406263e7 [2] https://kojipkgs.fedoraproject.org/compose/twoweek/Fedora-Atomic-25-20170620.1/compose/CloudImages/x86_64/images/Fedora-Atomic-25-20170620.1.x86_64.qcow2
(In reply to Dusty Mabe from comment #16) > I don't think this actually affects F25AH. The commit [1] from the #797 PR > you linked to #797 only made it into 2017.6, which wasn't in F25. > > ``` > $ koji latest-build f25-updates ostree > Build Tag Built by > ---------------------------------------- -------------------- > ---------------- > ostree-2017.6-2.fc25 f25-updates walters correction - that is 2017.6 in f25, but i still don't know why we don't see the problem as shown by the restorecon output.
ok - more info now - the qcow images we create most likely are built with an older ostree (from the installer), which means they won't show the problem, but if we do an upgrade/deploy the files will get relabeled with an incorrect label. I verified this behavior and that it is fixed with the new RPM in testing.
ostree-2017.7-2.fc25 has been pushed to the Fedora 25 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-2017-d194990d45
ostree-2017.7-2.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-2017-7b464a11e7
ostree-2017.7-2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
ostree-2017.7-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.