Bug 1197802

Summary:	Import of puppet module fails when using restrictive umask on the satellite server
Product:	Red Hat Satellite	Reporter:	pgustafs
Component:	Content Management	Assignee:	satellite6-bugs <satellite6-bugs>
Status:	CLOSED NOTABUG	QA Contact:	Katello QA List <katello-qa-list>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.0.7	CC:	akofink, bbuckingham, bkearney, mhrivnak, pierre-yves.goubet, sthirugn
Target Milestone:	Unspecified	Keywords:	Triaged
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-08-01 14:18:23 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 pgustafs 2015-03-02 16:17:31 UTC

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:

Comment 1 RHEL Program Management 2015-03-03 05:21:54 UTC

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.

Comment 3 Brad Buckingham 2015-12-11 19:59:45 UTC

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?

Comment 4 Michael Hrivnak 2015-12-23 20:04:40 UTC

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.

Comment 9 Andrew Kofink 2016-07-22 14:45:36 UTC

Created redmine issue http://projects.theforeman.org/issues/15795 from this bug

Comment 10 Bryan Kearney 2016-07-22 16:05:49 UTC

Upstream bug component is WebUI

Comment 11 Brad Buckingham 2016-08-01 14:18:23 UTC

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.