The cockpit-agent line like this: +/usr/libexec/cockpit-agent -- gen_context(system_u:object_r:shell_exec_t,s0) Should be in the cockpit file_contexts and in the cockpit module. The problem arises when in our integration tests upstream, when we try to test with selinux. We have to replace the cockpit selinux module with our own customized version (because of new features that have landed upstream, but not yet in Fedora). Because the above line is not in the cockpit module in selinux-policy-targetted, we get this failure: [stef@stef cockpit]$ sudo semodule -i x86_64/cockpit.pp [sudo] password for stef: /etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /usr/libexec/cockpit-agent. /etc/selinux/targeted/contexts/files/file_contexts: Invalid argument libsemanage.semanage_install_active: setfiles returned error code 1. semodule: Failed!
+/usr/libexec/cockpit-agent -- gen_context(system_u:object_r:shell_exec_t,s0) needs to belong to corecommands.pp because shell_exec_t comes from this module. It's about modularity. Why not just add cockip_test.pp or something like this. It could raise another issues if you replace a module which we shipped.
(In reply to Miroslav Grepl from comment #1) > +/usr/libexec/cockpit-agent -- > gen_context(system_u:object_r:shell_exec_t,s0) > > needs to belong to corecommands.pp because shell_exec_t comes from this > module. It's about modularity. > > Why not just add cockip_test.pp or something like this. It could raise > another issues if you replace a module which we shipped. Because we need to be able to take out rules/declarations as well as add them. It's not just about adding rules until the Cockpit integration tests work. If we wanted that, we could just run with 'setenforce 0'.
Work around in cockpit: https://github.com/cockpit-project/cockpit/commit/6f6f7535dcbdcbfa6cdd1a5ff061687a2e1a687e