Description of problem: I failed to export templates using tfm-rubygem-foreman_templates-9.1.0-1.el7sat.noarch However, I am not able to reproduce the issue using tfm-rubygem-foreman_templates-9.0.2-1.el7sat.noarch Version-Release number of selected component (if applicable): tfm-rubygem-foreman_templates-9.1.0-1.el7sat.noarch How reproducible: Every time Steps to Reproduce: mkdir -p /tmp/katello-export-test/test chmod 777 -R /tmp/katello-export-test/ chown -R foreman:foreman /tmp/katello-export-test/ setenforce 0 hammer --debug export-templates --commit-msg "Test message" --dirname foobar --filter "Alterator*" --metadata-export-mode keep --negate 0 --organization-id 1 --repo /tmp/katello-export-test/test --verbose 1 Actual results: Error message: Using file-based synchronization, but couldn't access /tmp/katello-export-test/test. Please check the access permissions/SELinux and make sure it is readable/writable for the web application user account, typically 'foreman'. Expected results: Passed hammer command with output "Export finished." Additional info: Bug found during the verification of BZ1964234.
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.
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.