Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default mode on config.json and service files is too permissive #199

Closed
lchi opened this issue Dec 4, 2015 · 2 comments · Fixed by #200
Closed

Default mode on config.json and service files is too permissive #199

lchi opened this issue Dec 4, 2015 · 2 comments · Fixed by #200

Comments

@lchi
Copy link

lchi commented Dec 4, 2015

I noticed that when provisioning configs (config.json or services via consul::service) the default file permissions are used. Since these files will likely have tokens in them, I was thinking the permissions should be more restrictive.

Thoughts on using something like mode => 0600? I'd be happy to open a PR.

@solarkennedy
Copy link
Contributor

600 sounds too restrictive, even for me, and would be inflexible to other who are integrating the tool with other tools. We are setting the group, so I would accept a PR for an explicit 660, and if people need to read it, they can add their users to the consul group of their choosing.

It is using the default mode for whatever puppet has for your system. Is your default mode 600?
https://docs.puppetlabs.com/puppet/latest/reference/lang_defaults.html

File {
  mode => '0600',
}

Or use an alternative method of overriding permissions of a file in puppet without modifying the code?
https://docs.puppetlabs.com/puppet/latest/reference/lang_classes.html#overriding-resource-attributes

@aj-jester
Copy link

I think we can have both by creating a class param for mode and defaulting it to 0660.

Also, we need to do this for any other configuration that has tokens; service.pp, check.pp and watch.pp.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants