Description of problem: Import of puppet modules fails when using an restrictive umask (0077) on the satellite 6 server. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. set umask to 0077 2. katello-service restart 3. create CV and add puppet modules to it 4. promote the CV 5. no new modules appears under Configure => Puppet Classes in the web UI 6. Listing /etc/puppet/environments/KT_CV_name_environment_X/modules will show that the permission on the module dir's is set to apache:apache and 700 Actual results: Expected results: Permission on module dir's should be set to apache:foreman-proxy and 750 even though an restrictive umask is used. Additional info:
Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
Hi Michael, are the permissions for the published puppet repositories (under /etc/puppet/environments/) controlled by the puppet_install_distributor? Can a pulp user control the ownership/permissions there?
Related work was done upstream that will appear in pulp 2.8.0: https://pulp.plan.io/issues/1289 https://github.com/pulp/pulp_puppet/commit/cef8643c12a0f600d12917c662cea0214b63435a Quoting the docs added in that PR, pulp will ensure "minimum permissions of 0644 for regular files and 0755 for directories". That said, pulp does not attempt to override the umask. Pulp opens each new file for writing with permissions that match the above-stated minimums, writes the file, and closes it. If the umask did aggressive masking, pulp could in theory go back for a second pass and chmod every file and directory it just created, but today pulp does not. I would suggest that the customer not run processes with a umask that is more restrictive than the permissions they expect on new files. Pulp does not facilitate controlling the group ownership of those files. Keep in mind that if pulp offered that as an option, the user (or maybe the installer) would have to ensure that the "apache" user is a member of whatever group they wanted to own the files.
Created redmine issue http://projects.theforeman.org/issues/15795 from this bug
Upstream bug component is WebUI
Closing this bugzilla based on the feedback in comment 4. In addition, the referenced case was closed after the puppet modules were created in an environment with proper umask.