search

fedora-selinux / selinux-policy

selinux-policy for Fedora is a large patch off the mainline
GNU General Public License v2.0
161 stars 162 forks source link

Rename /var/run #2017

Closed zpytela closed 6 months ago

packit-as-a-service[bot] commented 6 months ago

Cockpit tests failed for commit 3e2c71e2e0daff1fb64bedb63c88b90549963e30. @martinpitt, @jelly, @mvollmer please check.

martinpitt commented 6 months ago

Hmm, "Failed to start firewalld.service: Connection timed out" in the run. I've never seen this before, and this is a very intrusive PR, so let's make sure it doesn't break anything. I retried.

martinpitt commented 6 months ago

No, this repeats, so it smells real -- somehow this breaks firewalld.

I tried to reproduce in a rawhide VM:

systemctl stop firewalld
dnf copr enable -y packit/fedora-selinux-selinux-policy-2017
dnf upgrade --repo 'copr*'
systemctl start firewalld

.. but that succeeds. However, after reboot, it completely falls over:

[  OK  ] Reached target remote-fs.target - Remote File Systems.
[   48.511211] systemd[1]: systemd-resolved.service: Main process exited, code=exited, status=1/FAILURE
[   48.512683] systemd[1]: systemd-resolved.service: Failed with result 'exit-code'.
[   48.513999] systemd[1]: Failed to start systemd-resolved.service - Network Name Resolution.
[FAILED] Failed to start systemd-resolved.service - Network Name Resolution.
[... several repeats ...]
[FAILED] Failed to start systemd-resolved.service - Network Name Resolution.
See 'systemctl status systemd-resolved.service' for details.
[   48.798851] systemd[1]: Reached target network.target - Network.
[  OK  ] Reached target network.target - Network.
[   48.800565] systemd[1]: Reached target network-online.target - Network is Online.
[  OK  ] Reached target network-online.target - Network is Online.
[   48.802394] systemd[1]: Reached target nss-lookup.target - Host and Network Name Lookups.
[  OK  ] Reached target nss-lookup.target - Host and Network Name Lookups.
[   48.808968] systemd[1]: Starting rpc-statd-notify.service - Notify NFS peers of a restart...
[   48.810080] (m-notify)[703]: rpc-statd-notify.service: Failed to connect stdout to the journal socket, ignoring: Permission denied

You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, or "exit"
to continue bootup.
Give root password for maintenance
(or press Control-D to continue): [   93.434023] systemd[1]: auditd.service: start operation timed out. Terminating.

[   93.483890] audit: type=1400 audit(1706774618.205:1688): avc:  denied  { rmdir } for  pid=1 comm="systemd" name="auditd.service" dev="tmpfs" ino=1088 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir permissive=0
[   93.493981] audit: type=1400 audit(1706774618.218:1689): avc:  denied  { write } for  pid=709 comm="(ate-utmp)" name="stdout" dev="tmpfs" ino=50 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=sock_file permissive=0
[   93.496959] (ate-utmp)[709]: systemd-update-utmp.service: Failed to connect stdout to the journal socket, ignoring: Permission denied
[   93.503736] systemd[1]: systemd-update-utmp.service: Main process exited, code=exited, status=1/FAILURE
[   93.505160] audit: type=1400 audit(1706774618.227:1690): avc:  denied  { write } for  pid=709 comm="systemd-update-" name="private" dev="tmpfs" ino=41 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=sock_file permissive=0

... and more

Feels like this needs some magic operation, like relabeling or so? There's a lot of var_t stuff here.

zpytela commented 6 months ago

This update requires also changes in rpm, refer to https://src.fedoraproject.org/rpms/selinux-policy/pull-request/395 A lot of adjustments yet needs to be done.

martinpitt commented 6 months ago

Ah, so perhaps the spec changes could be put here as well, to test it end to end?

zpytela commented 6 months ago

Ah, so perhaps the spec changes could be put here as well, to test it end to end?

I don't think it's worth the bothering. There have been a lot of testing in the background.

martinpitt commented 6 months ago

It's more like "maintain the .spec file completely upstream, so that downstream releases can be handled through packit", but of course also for testing the change here.

zpytela commented 6 months ago

It's more like "maintain the .spec file completely upstream, so that downstream releases can be handled through packit", but of course also for testing the change here.

There are such changes planned, and it is not just moving specfile.