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

Should files_remove_setuid be an Array? #3

Open
andylytical opened this issue Jul 9, 2021 · 2 comments
Open

Should files_remove_setuid be an Array? #3

andylytical opened this issue Jul 9, 2021 · 2 comments
Labels
enhancement New feature or request

Comments

@andylytical
Copy link
Member

profile_system_auth::kerberos::files_remove_setuid reads as if it should be an array.

Should this be changed?

Leave implementation as-is for now and see if any usage or functionality issues arise. There may be need to extend this functionality to additional files in the future and if so, then implementation can be reviewed then.

@andylytical andylytical added the enhancement New feature or request label Jul 9, 2021
@andylytical
Copy link
Member Author

Regarding: #2 (comment)
Long term, I think perhaps we should move this out of this profile and into more generic security hardening module/profile that can address multiple issues like setuid, setgid, etc.

I think all items related to a given service should be managed only by the module or profile that configures it. Otherwise, we run into issues like:

  • multiple modules attempt to control the same resource (ie: the same file)
  • service related items are spread out in multiple places making it unclear where a given resource is managed

Using kerberos for example, I'd prefer that all kerberos related settings / changes remain in one place, such as puppet-kerberos. In fact, the setuid change probably belongs there (kerberos module) more than here (system auth).

@billglick
Copy link
Member

profile_system_auth::kerberos::files_remove_setuid is a Hash specifically to:

  1. allow it to be overridden with other modes. Perhaps that will never be necessary?
  2. allow it to be ensured via ensure_resources, which I think requires a Hash parameter.

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

No branches or pull requests

2 participants