Bug 1983146
| Summary: | File-based synchronization: Permission error | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Ondrej Gajdusek <ogajduse> |
| Component: | Templates Plugin | Assignee: | satellite6-bugs <satellite6-bugs> |
| Status: | CLOSED WONTFIX | QA Contact: | Ondrej Gajdusek <ogajduse> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.10.0 | CC: | lzap, mhulan |
| Target Milestone: | Unspecified | Keywords: | 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: | 2022-10-28 18:05:34 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
Ondrej Gajdusek
2021-07-16 16:33:31 UTC
Is this a bug or expected behavior? Note that SELinux prevents the app from touch directories other than we specifically allow it to touch. We can't tell what directories user want to export the templates to. Perhaps Lukas knows what directories would be recommended. Given Satellite uses private temp dirs, it shouldn't be accessing /tmp Following the Satellite documentation, I was able to successfully export the templates. mkdir -p /usr/share/templates_dir/ chown foreman:foreman /usr/share/templates_dir/ chcon -R -t httpd_sys_rw_content_t /usr/share/templates_dir/ hammer export-templates --organization 'Default Organization' --repo /usr/share/templates_dir However, I can not find a reason why Foreman is not able to export templates in the case when the 'foreman' user is an owner of the directory we are syncing into, with rwx permissions and SELinux is disabled. I found a workaround for the permissions issue. I did all steps from the BZ description but replaced the hammer command with the following foreman-rake. foreman-rake templates:export filter='Alterator*' repo=/tmp/katello-export-test/ metadata_export_mode='keep' dirname=foobar If the user is not able to export the templates using Foreman API, he should not be able to do so using foreman-rake. I expect that both approaches would work or none of them would work. Question: Is it regression or is it an expected behavior. As we discussed yesterday, try to restart the Foreman proces (service foreman restart) after disabling the SELinux. It could also be, that since Foreman now runs as puma process and not under the Apache, a different SELinux context may be necessary to modify. The foreman-rake is a workaround but not something we'd recommend as it skips permissions check entirely and as documentation suggests, it's deprecated. Lzap, any thoughts on SELinux, are changes to docs needed after migrating to Puma based deployment? Keep in mind systemd runs foreman service with private temporary directories. In this case, /tmp becomes something like /tmp/systemd-private-XYZ. So even if you create a path, foreman process will not see it. I think you should generally avoid using temporary directory for this case, try /var/lib/foreman/export or something. I think we should ship such a directory and it should already have the correct owner, permissions and SELinux by default and the template plugin should use it as the default destination. For the record, services do not need to be restarted in order to be allowed by SELinux, it works effectively immediately when you enable, disable or make permissive or load a new rule. Documentation update: https://github.com/theforeman/foreman-documentation/pull/620 Lukas, Thanks for the clarification around the /tmp dir and SELinux. I agree with the idea that you presented. Is it possible to create such directory, set the right SELinux context for it, and ship it with Sat 6.10? If this change happens, it would be great to reflect it in the product documentation. This is absolutely possible, I am just not finding time to implement it. It's an easy change, I can help with SELinux policy update if needed. Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team. Thank you. Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team. Thank you. Thank you for your interest in Red Hat Satellite. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this feel free to contact your Red Hat Account Team. Thank you. |