Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2232162

Summary: avc denial when importing templates to a local directory using API
Product: Red Hat Satellite Reporter: Peter Ondrejka <pondrejk>
Component: Templates PluginAssignee: Adam Lazik <alazik>
Status: CLOSED CURRENTRELEASE QA Contact: Peter Ondrejka <pondrejk>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.14.0CC: alazik, aruzicka, egolov, ekohlvan, lzap, rlavi
Target Milestone: 6.14.0Keywords: AutomationBlocker, Documentation, Regression, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-10-17 12:29:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Peter Ondrejka 2023-08-15 16:25:26 UTC
Description of problem:

Importing templates to a local directory fails due to the avc denial. Even though the file has httpd_sys_rw_content_t assigned

Version-Release number of selected component (if applicable):
6.14

How reproducible:
always

Steps to Reproduce:
- To reproduce manually prepare a local file and import templates as described in https://access.redhat.com/documentation/en-us/red_hat_satellite/6.13/html/managing_hosts/synchronizing_templates_repositories_managing-hosts#Synchronizing_Templates_with_a_Local_Directory_Using_the_API_managing-hosts
- reproducible using robottelo automation too 

Actual results:

Api call fails with:
500 Server Error: Internal Server Error for url: https://<satellite_hostname>:443/api/v2/templates/import

automation logs say:

"error": {"message":"Using file-based synchronization, but couldn't access /usr/share/foreman_templates/vTioyEjTKn. Please check the access permissions/SELinux and make sure it is readable/writable for the web application user account, typically 'foreman'."}

aureport -a on satellite says 
8/15/2023 12:03:29 puma srv tp 002 system_u:system_r:foreman_rails_t:s0 4 dir getattr unconfined_u:object_r:httpd_sys_rw_content_t:s0 denied 368

audit2allow -a

#============= foreman_rails_t ==============
allow foreman_rails_t httpd_sys_rw_content_t:dir getattr;


Expected results:
Success

Additional info:
- Reproducer available, not occurring in 6.13
- works with setenforce 0
- hit by robotello tests (e.g. tests/foreman/api/test_templatesync.py::TestTemplateSyncTestCase::test_positive_export_and_import_with_metadata)

Comment 1 Evgeni Golov 2023-08-22 07:07:21 UTC
Where does /usr/share/foreman_templates/vTioyEjTKn come from?

The /usr/share/foreman_templates/ seems rather odd to me.

Comment 3 Evgeni Golov 2023-08-22 07:24:06 UTC
in upstream bats, we explicitly use a folder underneath /usr/share/foreman/tmp for this test:
https://github.com/theforeman/forklift/blob/b807c692bf30c34f3821ef807e9e75d95562c3c2/bats/fb-test-foreman-templates.bats#L9

Comment 4 Peter Ondrejka 2023-08-22 09:24:44 UTC
Ad /usr/share/foreman_templates/vTioyEjTKn, it is just a custom dir the test creates to store templates, I suppose it was inspired by the docs where they use /usr/share/templates_dir/

Comment 5 Evgeni Golov 2023-08-22 09:45:23 UTC
Good point with the docs. /usr/share/templates_dir/ seems also odd, but that's for another BZ.

Still, I see no way how foreman_rails_t→httpd_sys_rw_content_t should have worked before.

Comment 6 Evgeni Golov 2023-08-22 09:57:53 UTC
On a 6.13, "selinux_check_access system_u:system_r:foreman_rails_t:s0 unconfined_u:object_r:httpd_sys_rw_content_t:s0 dir getattr" is happy.

On an upstream Katello 4.9 box, I get:
$ selinux_check_access system_u:system_r:foreman_rails_t:s0 unconfined_u:object_r:httpd_sys_rw_content_t:s0 dir getattr
avc:  denied  { getattr } for  scontext=system_u:system_r:foreman_rails_t:s0 tcontext=unconfined_u:object_r:httpd_sys_rw_content_t:s0 tclass=dir permissive=0
selinux_check_access: Permission denied

Now, go figure why /me scratches head

Comment 7 Evgeni Golov 2023-08-22 10:04:43 UTC
Aha, I think it's because of https://github.com/Katello/katello-selinux/commit/795588bb01a03d8d5b397e509dbc386cc5f5ec83

Now, I wonder what the correct fix should be. Allowing httpd_sys_rw_content_t again or using a different label for the files?

httpd_sys_rw_content_t seems like the wrong context for the foreman_templates files -- maybe foreman_lib_t would be correct?

Comment 8 Ewoud Kohl van Wijngaarden 2023-08-22 16:21:49 UTC
Feels like a documentation bug to me. I'd expect that if you use /var/lib/foreman/templates instead of /usr/share/template_dir you don't need to mess with SELinux at all.

Comment 9 Peter Ondrejka 2023-08-23 14:20:04 UTC
If we change just the docs, we also need to warn users to move their templates to the new recommended location after the upgrade. I'd prefer not to break the old set-ups if we can solve it with labels

Comment 10 Lukas Zapletal 2023-08-28 08:21:42 UTC
I agree that httpd_sys_rw_content_t is some sort of a typo. Any context which foreman domain can read/write would be fine. What Ewoud recommends is the best solution I think as files will automatically have the correct context by default.

Comment 11 Evgeni Golov 2023-08-29 06:38:24 UTC
We discussed that BZ during Platform triage yesterday and came to the following result:

- users need put the templates somewhere where Foreman can read them (file permissions and selinux wise)
- httpd_sys_rw_content_t was an obstacle, and the wrong label to begin with
- foreman_lib_t is the correct label for such content

That means:
- if users put their templates in /var/lib/foreman/<something nice> it will get labeled correctly automatically
- if they put them somewhere else, they need to ensure the right (foreman_lib_t) SELinux label is applied

Therefore please update the docs to recommend a place in /var/lib/foreman and point out that other places need correct labeling.

As for existing setups: we decided against a release-note for this, this BZ should be sufficient to find the error message and the pointer at the updated docs.

Comment 12 Adam Lazik 2023-09-04 12:40:09 UTC
Created PR with the suggested changes:
https://github.com/theforeman/foreman-documentation/pull/2414