Feature #708
User and Group providers should directly parse /etc/passwd and /etc/group
| Status: | Rejected | Start date: | ||
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | user | |||
| Target version: | - | |||
| Affected Puppet version: | Branch: | |||
| Keywords: | ||||
| Votes: | 5 |
Description
The current user and group providers rely on the Etc module that ships with Ruby to figure out the current state of the system, but that library provides information about users and groups not manageable by Puppet.
Instead, the providers should use ParsedFile to directly parse the appropriate files.
History
Updated by Mike Barsalou almost 5 years ago
What about setting the uid? What OS is this?
Updated by Luke Kanies almost 5 years ago
Is there a way for Puppet to know which users are in the passwd.db but not in the passwd file?
Updated by Digant Kasundra almost 5 years ago
The only way I can currently think of is to actually parse the passwd file instead of using the libraries, though perhaps the libraries do offer a way (I’m not that familiar with them). Maybe the right approach is to have provider’s for users?
Updated by Luke Kanies over 4 years ago
I just can’t see a good way to fix this. Do we update the ‘resources’ type so that it knows enough about users to not purge users that should be in /etc/passwd but aren’t? Do we silently ignore any attempt at removing non-local users? Do we warn on every one?
I can’t see a good behaviour here.
Updated by Luke Kanies over 4 years ago
Marking #935 as a duplicate.
Updated by Luke Kanies about 4 years ago
I’m changing this ticket to what it should be: Getting rid of the usage of ‘Etc’, and just parsing the files directly.
Updated by Redmine Admin almost 4 years ago
- Status changed from 1 to Accepted
Updated by Luke Kanies about 2 years ago
- Assignee changed from Luke Kanies to Markus Roberts
Updated by Robert Scheer over 1 year ago
Luke Kanies wrote:
I just can’t see a good way to fix this. Do we update the ‘resources’ type so that it knows enough about users to not purge users that should be in /etc/passwd but aren’t? Do we silently ignore any attempt at removing non-local users? Do we warn on every one?
I can’t see a good behaviour here.
If the provider can’t add/delete/modify users in other password databases other than the local password file, then the test to see if a user exists should only look in that local file. That way, you completely ignore non-local users and you don’t need a way to deal with them.
We have the same problems as the creator of related ticket #935: puppet instructs usermod to manipulate users that are not local. That is simply because its test (getpwnam) is wrong. I hope you or Markus can fix this.
Updated by Robert Scheer over 1 year ago
Actually, the problem is bigger than just the puppet-test to see if a user exists: useradd/del/mod do exactly the same thing (getpwnam), so even if puppet would look only in /etc/passwd before executing those programs, useradd will not add a user that already exist in nis (or probably any other external user directory, like ldap), and userdel/mod will complain that a user that exists in nis cannot be found in /etc/passwd.
The only real solution seems to be what Derek Whayman suggested 3 years ago in #935 : let puppet parse and modify /etc/passwd and shadow directly, so it can ignore users from external directories completely.
My ruby skills are reading-only i’m afraid (and even that with difficulty), but if there is anything I can do to solve this problem, please tell me.
Updated by Nigel Kersten over 1 year ago
- Affected Puppet version deleted (
0.25.4rc1)
Just pointing out that for similar reasons we deliberately restrict the Mac user/group providers to the local domain, even though we do get to still use the sanctioned command line tools rather than parsing the backing data by hand, and even then we’ve run into the odd issue that has made us consider doing everything by hand.
Updated by Nigel Kersten over 1 year ago
- Target version deleted (
4)
Updated by Joshua Lifton 5 months ago
- Assignee deleted (
Markus Roberts)
This issue was assigned to a former Puppet Labs employee. Adding back to the pool of unreviewed issues.
Updated by Joshua Lifton 5 months ago
This issue was assigned to a former Puppet Labs employee. Adding back to the pool of unreviewed issues.
Updated by Ben Hughes 4 months ago
- Description updated (diff)
- Status changed from Accepted to Unreviewed
Updated by Daniel Pittman 4 months ago
- Description updated (diff)
- Status changed from Unreviewed to Rejected
I appreciate the desire to manage only local resources, and thus to show only them, but the definition of “what can be managed” is going to vary enough site-to-site that we literally cannot determine this ahead of time.
As an example, it is quite reasonable for someone using an SQL database backed NSS and PAM set to manipulate their “local” accounts with Puppet, even though those are stored in SQL and are absolutely, without question, not present in /etc/{passwd,group,shadow}.
We can’t get into the business of whitelisting the “approved” storage forms, so while I might entertain blacklisting some specific store for a specific problem, in the general case we are not going to do this on Linux and other traditional Unix systems that support a full, pluggable NSS system.