Neal Gompa <ngomp...@gmail.com> writes: > On Thu, May 29, 2025 at 6:16 AM Richard W.M. Jones <rjo...@redhat.com> wrote: >> >> [This is a general moan / observation ... Sorry!] >> >> SELinux policy is sometimes now split so that packages can carry their >> own policy subpackage. Examples include: >> >> https://src.fedoraproject.org/rpms/passt/blob/rawhide/f/passt.spec#_36 >> https://src.fedoraproject.org/rpms/nbdkit/blob/rawhide/f/nbdkit.spec#_751
one thing it could be simply fixed: https://src.fedoraproject.org/rpms/passt/blob/rawhide/f/passt.spec#_91 There's no need to run the macro 3 times - all modules can be installed in one run using %selinux_modules_install -s %{selinuxtype} \ %{_datadir}/selinux/packages/%{selinuxtype}/passt.pp \ %{_datadir}/selinux/packages/%{selinuxtype}/pasta.pp \ %{_datadir}/selinux/packages/%{selinuxtype}/passt-repair.pp >> >> I've recently been installing a lot of VMs with virt-v2v, and of the >> approximately 3 minutes spent installing the required packages, I'd >> estimate that around 2 minutes is spent running the *-selinux >> post-install scripts for swtpm-seinux, passt-selinux and >> nbdkit-selinux. For some reason passt-selinux is particularly >> excessive (I eyeballed it at around 75 seconds). >> >> I wonder if there's a way we could have RPM rebuild the SELinux policy >> just once in this situation? And asking another level of "why", why >> is rebuilding the policy so slow in the first place? >> > > The problem is that policy modules can depend on each other, and since > policy modules can add things both to the global store and to the pool > of stuff other modules can use, it has to be processed serially. Well, no. If a policy rule depends on a type from another module which is not from base policy, it need to be in optional_policy block, https://fedoraproject.org/wiki/SELinux/IndependentPolicy#Custom_policy_modules_and_distribution_policy > This is why the historical policy was that everything needs to go into > selinux-policy itself. SELinux as a system isn't designed for modular > policies, as it's a system for centralized overlord-style control. There are two types of policy - monolithic and modular. Fedora has been using modular policy for ages. Also for almost 10 upstream releases, SELinux policy store supports priorities on modules. It means you can override base module with your changed module using a higher priority than 100. We use priorities to differentiate modules from selinux-policy package - priority 100, from -selinux subpackages - priority 200, setroubleshoot suggests to use priority 300 and local user modules uses default priority 400 https://github.com/SELinuxProject/selinux-notebook/blob/main/src/types_of_policy.md https://plautrba.fedorapeople.org/selinux-modules-and-priority.html > There is definitely some stupid stuff still, though: like > selinux-policy having a vendored copy of container-selinux and the > container tools still requiring their own container-selinux package > anyway. It should be one way or another, not both because it creates > install and upgrade problems occasionally (in addition to the slow > performance issue). > This is much more complicated and the issue is originated in times when container policy was part of Fedora policy. It didn't scale, container team needed to progress much faster then selinux-policy team was able to. > > Another issue is that we don't have a good way to do selective > relabeling based on the module being installed, and while the SELinux > tools support multi-threaded operations, it's not the default and none > of the macros use it. And from an image builder perspective, there are > also issues with SELinux tools being very hard to use to set up > policies offline as well. > This is not correct. There's %selinux_relabel_pre macro which stores file contexts before policy is installed, and %selinux_relabel_post which relabels only directories affected by the change in policy - this is not perfect though as in some cases it could cause relabeling of the whole fs https://fedoraproject.org/wiki/SELinux/IndependentPolicy#The_%prep_and_%install_Section https://bugzilla.redhat.com/show_bug.cgi?id=2318279 > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > -- > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
