From Fedora Project Wiki
(Provide answers)
mNo edit summary
 
(One intermediate revision by one other user not shown)
Line 18: Line 18:
*  do we have to maintain all the `.fc` paths, also related to e.g. debian (as is done in selinux-policy-targeted)
*  do we have to maintain all the `.fc` paths, also related to e.g. debian (as is done in selinux-policy-targeted)
** Not sure if I understand the question, but the .fc file is necessary because it completely overrides the .fc contained in selinux-policy-targeted
** Not sure if I understand the question, but the .fc file is necessary because it completely overrides the .fc contained in selinux-policy-targeted
*** Check e.g.  ./policy/modules/services/postgresql.fc, and the line "ifdef(`distro_debian'," ... do we have to cross-sync those parts between postgresql-selinux and selinux-policy-targeted?
**** Only if you want your policy to work on debian. You shouldn't change (or remove) the file context rules specified in the distribution policy package since other policy modules may rely on them (and the distribution policy is overridden by the custom module since it has higher priority), but in this case the change has no effect on Fedora. 
* if something changes in say mysql-selinux, do we have to backport it to selinux-policy-targeted upstream?
* if something changes in say mysql-selinux, do we have to backport it to selinux-policy-targeted upstream?
** changes should be backported to selinux-policy-targeted
** changes should be backported to selinux-policy-targeted

Latest revision as of 09:55, 2 October 2018

general questions

  • can the reasons for %defattr 755 be explained?
    • No, it was a leftover from selinux-policy.spec and will be removed
  • what if one package aims foo-selinux wants to generate foo-selinux-targeted and foo-selinux-mls? (e.g. see copr-selinux) answer: all the %selinux_* macros provide -s option
    • There would be two new .tars and most changes to the spec file would appear twice (once for each package).
    • The naming convention is up to the maintainer. It would probably be best to use "foo-selinux" for the "targeted" policy and "foo-selinux-mls" for "mls"
  • shouldn't we move %selinux_relabel_post to %post (instead of %posttrans) or move the %selinux_relabel_pre into %pretrans? The former is much more flexible, but probably a lot less optimal.
    • The selinux_relabel_pre macro takes effect only once per transaction (the first package to use it copies current file_contexts file)
    • This is why selinux_relabel_post is called in posttrans (it evaluates all policy changes in the transaction and relabels files accordingly)
  • should packages Recommend/Require the 'foo-selinux' packages? (consider selinux is enforcing, and people install foo-bar package, but forgot to install foo-selinux), edit: I do think that we should use Requires: (foo-selinux-targeted if selinux-policy-targeted), WDYT?
    • Yes, they should. We already started using the rich dependency syntax in one package to test it properly. I'll add it into the guidelines
  • can anyone from selinux team review this POC https://pagure.io/copr/copr/pull-request/301 (no matter when)

policy to sync with global selinux policy?

  • do we have to maintain all the .fc paths, also related to e.g. debian (as is done in selinux-policy-targeted)
    • Not sure if I understand the question, but the .fc file is necessary because it completely overrides the .fc contained in selinux-policy-targeted
      • Check e.g. ./policy/modules/services/postgresql.fc, and the line "ifdef(`distro_debian'," ... do we have to cross-sync those parts between postgresql-selinux and selinux-policy-targeted?
        • Only if you want your policy to work on debian. You shouldn't change (or remove) the file context rules specified in the distribution policy package since other policy modules may rely on them (and the distribution policy is overridden by the custom module since it has higher priority), but in this case the change has no effect on Fedora.
  • if something changes in say mysql-selinux, do we have to backport it to selinux-policy-targeted upstream?
    • changes should be backported to selinux-policy-targeted
  • should we maintain paths for SCLs? Or should each SCL have it's own '*-selinux' package with custom paths?
    • each SCL should have it's own *-selinux package with files stored in the selinux store (/var/lib/selinux)
  • should there be e.g. separated policy for mariadb vs. mysql?
    • this is a special case and should be consulted with the SELinux team (in this case there would probably be a shared database-selinux package)