From Fedora Project Wiki
(POC review request) |
(Provide answers) |
||
Line 3: | Line 3: | ||
* can the reasons for %defattr 755 be explained? | * 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''' | * 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. | * 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? | * 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) | * can anyone from selinux team review this POC https://pagure.io/copr/copr/pull-request/301 (no matter when) | ||
** I created a ticket for it in our Jira (it will be assigned during our next planning meeting) https://projects.engineering.redhat.com/browse/SELINUX-1434 | |||
== policy to sync with global selinux policy? == | == 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) | * 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 | |||
* 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 | |||
* should we maintain paths for SCLs? Or should each SCL have it's own '*-selinux' package with custom paths? | * 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? | * 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) |
Revision as of 15:50, 1 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)
- I created a ticket for it in our Jira (it will be assigned during our next planning meeting) https://projects.engineering.redhat.com/browse/SELINUX-1434
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
- 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)