Separate domtrans/run interfaces for portage_fetch
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v2 Latest4 patches 0 repliesNew
- v11 patch 0 repliesSuperseded
Changes in v2 from the cover letter
----------------
- Removes the portage_fetch_t calls from portage_domtrans and portage_run
- Adds callers for portage_fetch_t (sysadm, unconfined and puppet for now)
Patches in v2 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/4 | Separate domtrans/run interfaces for portage_fetchportage.if | +52 | 0 replies | |
| 2/4 | Allow puppet to call portagepuppet.te | +6 | 0 replies | |
| 3/4 | Allow sysadm_t to call all portage related servicespolicy/ | +1 | 0 replies | |
| 4/4 | Allow unconfined users to call portage featurespolicy/ | +6 | 1 reply |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.
Cover letter [refpolicy] [PATCHv2 0/4] Separate domtrans/run interfaces for portage_fetch
This revised patchset updates the portage interfaces to support portage_run_fetch and portage_domtrans_fetch, rather than including the support for portage_fetch_t in the regular portage_run and portage_domtrans interfaces.
I'm not sure how to best "mix" changes across refpolicy and refpolicy::contrib. If the patches are not correctly made, this was what I did:
- Make changes in contrib, then format-patch to generate patches
- Make changes in refpolicy, then format-patch to generate patches
I notice that git also supports "adding" the commits from contrib to the patches in the main refpolicy, but I'm not sure that's the idea behind it for refpolicy.
Changes since v1
----------------
- Removes the portage_fetch_t calls from portage_domtrans and portage_run
- Adds callers for portage_fetch_t (sysadm, unconfined and puppet for now)