Jira (PUP-8470) Unable to modify local user group membership with forcelocal

6 views
Skip to first unread message

Chuck Schweizer (JIRA)

unread,
Feb 19, 2018, 3:00:03 PM2/19/18
to puppe...@googlegroups.com
Chuck Schweizer created an issue
 
Puppet / Bug PUP-8470
Unable to modify local user group membership with forcelocal
Issue Type: Bug Bug
Affects Versions: PUP 5.4.0
Assignee: Eric Sorenson
Components: Community, Types and Providers
Created: 2018/02/19 11:59 AM
Priority: Normal Normal
Reporter: Chuck Schweizer

Puppet Version: 5.4.0
Puppet Server Version: 5.2.0
OS Name/Version: RHEL 7

 

group { 'group1' :
ensure => present,
gid => '901',
forcelocal => true,
}

group { 'group2' :
ensure => present,
gid => '902',
forcelocal => true,
}

user { 'user1' :
ensure => present,
home => '/home/user1',
uid => '900',
gid => 'user1',
comment => 'user1',
shell => '/bin/bash',
forcelocal => true,
managehome => true,
groups => ['group1', 'group2'],
require => Group['group1', 'group2'],
}

So far I have found two issues.

1) lusermod does not support -G

  1. lusermod --help
    Usage: lusermod [OPTION...] user
    -i, --interactive prompt for all information
    -c, --gecos=STRING GECOS information
    -d, --directory=STRING home directory
    -m, --movedirectory move home directory contents
    -s, --shell=STRING set shell for user
    -u, --uid=NUM set UID for user
    -g, --gid=NUM set primary GID for user
    -l, --login=STRING change login name for user
    -P, --plainpassword=STRING plaintext password for the user
    -p, --password=STRING pre-hashed password for the user
    -L, --lock lock account
    -U, --unlock unlock account
    --commonname=STRING set common name for user
    --givenname=STRING set given name for user
    --surname=STRING set surname for user
    --roomnumber=STRING set room number for user
    --telephonenumber=STRING set telephone number for user
    --homephone=STRING set home telephone number for user

Help options:
-?, --help Show this help message
--usage Display brief usage message

2) the new code will not "modify" the user's groups in /etc/group because the user already exists.

Desired Behavior: 
user type allowed to modify local users groups

Actual Behavior:

Error: UID 900 already exists, use allowdupe to force user creation
Error: /Stage[main]/Localusers::Identities/User[user1]/groups: change from to 'group1,group2' failed: UID 900 already exists, use allowdupe to force user creation

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.5.1#75006-sha1:7df2574)
Atlassian logo

Chuck Schweizer (JIRA)

unread,
Feb 19, 2018, 3:15:03 PM2/19/18
to puppe...@googlegroups.com
Chuck Schweizer updated an issue
Change By: Chuck Schweizer
*Puppet Version: 5.4.0*
*Puppet Server Version: 5.2.0*
*OS Name/Version: RHEL 7*

  Breaking Change: https://tickets.puppetlabs.com/browse/PUP-8223

group \{ 'group1' :
ensure => present,
gid => '901',
forcelocal => true,
}

group \{ 'group2' :
ensure => present,
gid => '902',
forcelocal => true,
}

user \{ 'user1' :
ensure => present,
home => '/home/user1',
uid => '900',
gid => 'user1',
comment => 'user1',
shell => '/bin/bash',
forcelocal => true,
managehome => true,
groups => ['group1', 'group2'],
require => Group['group1', 'group2'],
}


So far I have found two issues.

1) lusermod does not support -G

# lusermod --help

Usage: lusermod [OPTION...] user
-i, --interactive prompt for all information
-c, --gecos=STRING GECOS information
-d, --directory=STRING home directory
-m, --movedirectory move home directory contents
-s, --shell=STRING set shell for user
-u, --uid=NUM set UID for user
-g, --gid=NUM set primary GID for user
-l, --login=STRING change login name for user
-P, --plainpassword=STRING plaintext password for the user
-p, --password=STRING pre-hashed password for the user
-L, --lock lock account
-U, --unlock unlock account
--commonname=STRING set common name for user
--givenname=STRING set given name for user
--surname=STRING set surname for user
--roomnumber=STRING set room number for user
--telephonenumber=STRING set telephone number for user
--homephone=STRING set home telephone number for user

Help options:
-?, --help Show this help message
--usage Display brief usage message

2) the new code will not "modify" the user's groups in /etc/group because the user already exists.

*Desired Behavior:* 
user type allowed to modify local users groups

*Actual Behavior:*


Error: UID 900 already exists, use allowdupe to force user creation
Error: /Stage[main]/Localusers::Identities/User[user1]/groups: change from to 'group1,group2' failed: UID 900 already exists, use allowdupe to force user creation

Chuck Schweizer (JIRA)

unread,
Feb 19, 2018, 3:42:02 PM2/19/18
to puppe...@googlegroups.com
Chuck Schweizer updated an issue
*Puppet Version: 5.4.0*
*Puppet Server Version: 5.2.0*
*OS Name/Version: RHEL 7*

Breaking Change: https://tickets.puppetlabs.com/browse/PUP-8223

I also validated this is broken when using a puppet apply with this code.

Josh Cooper (JIRA)

unread,
Feb 20, 2018, 12:20:03 PM2/20/18
to puppe...@googlegroups.com
Josh Cooper updated an issue
Change By: Josh Cooper
*Puppet Version: 5.4.0*
*Puppet Server Version: 5.2.0*
*OS Name/Version: RHEL 7*

Breaking Change: https://tickets.puppetlabs.com/browse/PUP-8223

I also validated this is broken when using a puppet apply with this code.

{code:puppet}
group \ { 'group1' :
ensure => present,
gid => '901',
forcelocal => true,
}

group
\ { 'group2' :
ensure => present,
gid => '902',
forcelocal => true,
}

user
\ { 'user1' :
ensure => present,
home => '/home/user1',
uid => '900',
gid => 'user1',
comment => 'user1',
shell => '/bin/bash',
forcelocal => true,
managehome => true,
groups => ['group1', 'group2'],
require => Group['group1', 'group2'],
}
{code}

Josh Cooper (JIRA)

unread,
Feb 20, 2018, 12:20:05 PM2/20/18
to puppe...@googlegroups.com

Josh Cooper (JIRA)

unread,
Feb 20, 2018, 12:21:02 PM2/20/18
to puppe...@googlegroups.com

Josh Cooper (JIRA)

unread,
Feb 20, 2018, 12:23:02 PM2/20/18
to puppe...@googlegroups.com
Josh Cooper assigned an issue to Unassigned
Change By: Josh Cooper
Assignee: Eric Sorenson

Josh Cooper (JIRA)

unread,
Feb 20, 2018, 12:23:15 PM2/20/18
to puppe...@googlegroups.com
Josh Cooper updated an issue
{noformat}
Error: UID 900 already exists, use allowdupe to force user creation
Error: /Stage[main]/Localusers::Identities/User[user1]/groups: change from to 'group1,group2' failed: UID 900 already exists, use allowdupe to force user creation

{noformat}

Josh Cooper (JIRA)

unread,
Feb 20, 2018, 12:24:03 PM2/20/18
to puppe...@googlegroups.com

Melissa Stone (JIRA)

unread,
Feb 20, 2018, 12:26:04 PM2/20/18
to puppe...@googlegroups.com

Melissa Stone (JIRA)

unread,
Feb 20, 2018, 12:26:04 PM2/20/18
to puppe...@googlegroups.com

Trey Dockendorf (JIRA)

unread,
Feb 20, 2018, 5:51:03 PM2/20/18
to puppe...@googlegroups.com
Trey Dockendorf commented on Bug PUP-8470
 
Re: Unable to modify local user group membership with forcelocal

Looks like local group modifications are done through lgroupmod

-M, --member-add=list               
Add users in comma-separated list among group's members.

Melissa Stone (JIRA)

unread,
Feb 20, 2018, 5:53:03 PM2/20/18
to puppe...@googlegroups.com
Melissa Stone commented on Bug PUP-8470

That is an option, but apparently groupadd doesn't have support for that yet

Debug: /Group[group1]: Provider groupadd does not support features manages_members; not managing attribute members

Trey Dockendorf (JIRA)

unread,
Feb 20, 2018, 5:57:03 PM2/20/18
to puppe...@googlegroups.com

Would it be appropriate to have the useradd provider execute lgroupmod when forcelocal is true and a groups is defined?

Melissa Stone (JIRA)

unread,
Feb 21, 2018, 11:31:03 AM2/21/18
to puppe...@googlegroups.com

Melissa Stone (JIRA)

unread,
Feb 21, 2018, 1:02:03 PM2/21/18
to puppe...@googlegroups.com
Melissa Stone commented on Bug PUP-8470
 
Re: Unable to modify local user group membership with forcelocal

Okie dokies, it seems there are a few things we need to fix here.

First, the main issue I'm seeing with your original PR, Trey Dockendorf, is that I glossed over the fact that modifycmd should only call `check_allow_dup` if we're modifying either the uid or the gid of the resource. That's how it used to work and we lost that when I had you just use the existing `check_allow_dup` method in useradd.rb and groupadd.rb. That will fix the failure about modifying a duplicate resource.

Second, we ran into a fun little quirk with Puppet::Util::Execution.execute. When no additional options are passed in, :failonfail will default to true which is what we want. However, we changed that call to pass in the custom environment if we are using forcelocal. Because that was an additional option passed into execute, failonfail is now being set to false. So `lusermod` was failing because it didn't recognize the `-G` flag, but that failure wasn't failing the puppet run. That is not what we want.

I'll have prs up for the above two things in the next hour.

The final bit is more complex, and I'd like to get Eric Sorenson to weigh in on it. This is technically a bug fix. Previously when you were modifying a user or a group and forcelocal was true, it would call out to `usermod` or `groupmod`. It should be calling `lusermod` or `lgroupmod`. Otherwise we could be modifying the user or group on the local system or on a remote system, depending on how the environment is set up. That could potentially leave users in an inconsistent state which isn't ideal. However, this is a significant behavior change. The local commands `lusermod` and `lgroupmod` don't have the same capabilities as `usermod` or `groupmod`. Group management, for instance, is something `usermod` can handle but `lusermod` cannot. We have a few options on how to move forward with this. We can revert this change and retarget it at Puppet 6.0.0 or we can leave this change in the 5.4.x series. In either scenario, we'd need to update groupadd.rb to have the feature `manages_members`. That may have some additional complications, though I haven't dug into it at all. This would also necessitate a change in how users are managing group membership, i.e. in the group resource rather than the user resource. I'm sure there are more options I haven't thought of either, but those two seem like the most reasonable. We could also do what Trey suggested, where we call out to lgroupmod from useradd.rb, but that almost feels like too much to ask of useradd.rb.

Kenn Hussey (JIRA)

unread,
Feb 21, 2018, 5:41:04 PM2/21/18
to puppe...@googlegroups.com
Kenn Hussey commented on Bug PUP-8470

Melissa Stone we're not currently planning a 5.4.1 release, so targeting this at 5.5.0 (master).

Kenn Hussey (JIRA)

unread,
Feb 21, 2018, 5:41:04 PM2/21/18
to puppe...@googlegroups.com
Kenn Hussey updated an issue
 
Change By: Kenn Hussey
Fix Version/s: PUP 5.4.1
Fix Version/s: PUP 5.5.0

Eric Sorenson (JIRA)

unread,
Feb 21, 2018, 7:20:03 PM2/21/18
to puppe...@googlegroups.com
Eric Sorenson commented on Bug PUP-8470
 
Re: Unable to modify local user group membership with forcelocal

I've just spent like 20 minutes trying to understand this problem and I'm starting to believe I'm not smart enough to really get it.

There's always been an orthogonality to the user/group management split, because group membership can be both a property of the group and a property of each user in that group. The docs guidance says that you should use group resources just to create/remove groups, and manage group membership as a property of the user resources, except for some group providers like macOS and Windows which, as you note Melissa, have manages_members on them. I think this ought to be the exception. Group membership management should continue to primarily be the responsibility of the user resources. Therefore the problem case is when:

  • forcelocal is true for the user
  • system configuration points at a remote mechanism for group management.

Interestingly, the man page for usermod on RHEL says:

You may not add a user to a NIS or LDAP group. This must be performed on the corresponding server.

Similarly, if the username already exists in an external user database such as NIS or LDAP, useradd will deny
the user account creation request.

So maybe we just keep using usermod, and let the underlying system error out if that is an invalid configuration?

Trey Dockendorf (JIRA)

unread,
Feb 21, 2018, 7:44:02 PM2/21/18
to puppe...@googlegroups.com

If the user resource should keep being responsible for the management of membership then would seem logical to have forcelocal=>true trigger lgroupmod if a user resource has groups defined.  I'd be happy to write the PR for this if acceptable to Puppet folks.

That exert describes an invalid configuration for usermod, but not for lusermod which is why I thought forcelocal existed, to force creation into /etc/passwd even if the record exists in LDAP.  This can be extremely useful for critical services where LDAP connectivity should not impact service reliability.  The original motivation for my original PR was to fix forcelocal to change a user or group's UID/GID even when that user/group existed in LDAP.  The goal in my case was to make a /etc/passwd entry added by a package also match LDAP.  It's often the case that packages add user/groups and sometimes that happens before LDAP exists or even if it exists in LDAP and the UID/GID isn't always consistent and thus Puppet is perfect tool to fix the divergence.

At least in RHEL the lusermod/lgroupmod comes from libuser and usermod/groupmod comes from shadow-utils, so separate packages that have a lot of functionality overlap but libuser does things that in Puppet are activated with forcelocal.

Chuck Schweizer (JIRA)

unread,
Feb 21, 2018, 8:24:02 PM2/21/18
to puppe...@googlegroups.com

Would it make sense for lusermod/lgroupmod to only be called for UID/GID changes?

Jacob Helwig (JIRA)

unread,
Feb 22, 2018, 2:06:04 PM2/22/18
to puppe...@googlegroups.com

Melissa Stone (JIRA)

unread,
Feb 23, 2018, 2:14:03 PM2/23/18
to puppe...@googlegroups.com
Melissa Stone commented on Bug PUP-8470

Trey Dockendorf it sounds like your proposal is the best to get this moving forward. That satisfies the requirements that Eric set out, and should fix this failure for Chuck. If you're still up for opening that pull request, that would be fantastic! 

Trey Dockendorf (JIRA)

unread,
Feb 23, 2018, 3:47:04 PM2/23/18
to puppe...@googlegroups.com

I can't tell if the membership parameter, https://puppet.com/docs/puppet/5.3/type.html#user-attribute-membership, applies to useradd provider.  It doesn't look like that parameter applies but wanted to double check.  If membership param is not used by useradd then sounds like the change needed would be to run "lgroupmod --member-add=<group> <user>" for each group in a user's groups property.

Chuck Schweizer (JIRA)

unread,
Feb 23, 2018, 8:24:03 PM2/23/18
to puppe...@googlegroups.com

Is there a reason you don’t want to use usermod for this? 

Trey Dockendorf (JIRA)

unread,
Feb 24, 2018, 2:31:03 PM2/24/18
to puppe...@googlegroups.com

I think usermod will work, so when forcelocal is true use lusermod for all but groups changes.

Eric Delaney (JIRA)

unread,
Mar 2, 2018, 1:04:04 PM3/2/18
to puppe...@googlegroups.com

Melissa Stone (JIRA)

unread,
Mar 2, 2018, 1:13:05 PM3/2/18
to puppe...@googlegroups.com
Melissa Stone updated an issue
 
Change By: Melissa Stone
Release Notes Summary: Currently `lusermod` has no way to manage group membership. Puppet is set up so that, in most cases, group membership is managed via the user resource. Now that setting `forcelocal => true` uses `lusermod` instead of `usermod`, we have lost the ability to manage group membership. This change ensures that `usermod` is called only when trying to manage group membership for a user resource. Depending on how the users environment is configured, this may or may not work. If we try to add a user to a NIS or LDAP group, the command will fail. This is consistent with the behavior of group membership management prior to Puppet 5.4.0.
Release Notes: Bug Fix

Eric Delaney (JIRA)

unread,
Mar 12, 2018, 5:11:03 PM3/12/18
to puppe...@googlegroups.com
Eric Delaney assigned an issue to Eric Sorenson
Change By: Eric Delaney
Assignee: Melissa Stone Eric Sorenson

Eric Delaney (JIRA)

unread,
Mar 12, 2018, 5:13:04 PM3/12/18
to puppe...@googlegroups.com
Eric Delaney assigned an issue to Unassigned
Change By: Eric Delaney
Assignee: Eric Sorenson

Eric Delaney (JIRA)

unread,
Mar 12, 2018, 5:30:04 PM3/12/18
to puppe...@googlegroups.com

Eric Delaney (JIRA)

unread,
Mar 12, 2018, 6:08:04 PM3/12/18
to puppe...@googlegroups.com
Eric Delaney commented on Bug PUP-8470
 
Re: Unable to modify local user group membership with forcelocal

tested on 5.5.x SHA=68d2b2e715fa815623200044a67ce31ce3b4d3ef

[root@h3oycahh6hc35wl ~]# puppet apply t.pp
Notice: Compiled catalog for h3oycahh6hc35wl.delivery.puppetlabs.net in environment production in 0.03 seconds
Notice: /Stage[main]/Main/Group[group1]/ensure: created
Notice: /Stage[main]/Main/Group[group2]/ensure: created
Notice: /Stage[main]/Main/User[user1]/ensure: created
Notice: Applied catalog in 0.18 seconds
[root@h3oycahh6hc35wl ~]# grep group /etc/group
group1:x:901:user1
group2:x:902:user1
[root@h3oycahh6hc35wl ~]# grep user1 /etc/passwd
user1:x:900:1000:user1:/home/user1:/bin/bash
[root@h3oycahh6hc35wl ~]#

Eric Delaney (JIRA)

unread,
Mar 12, 2018, 6:09:04 PM3/12/18
to puppe...@googlegroups.com
Eric Delaney updated an issue
 
Change By: Eric Delaney
QA Risk Assessment: Needs Assessment No Action

Austin Boyd (JIRA)

unread,
Oct 22, 2019, 5:52:03 AM10/22/19
to puppe...@googlegroups.com
Austin Boyd updated an issue
Change By: Austin Boyd
Zendesk Ticket IDs: 32283
Zendesk Ticket Count: 1

Austin Boyd (JIRA)

unread,
Oct 22, 2019, 6:09:03 AM10/22/19
to puppe...@googlegroups.com

Austin Boyd (JIRA)

unread,
Dec 12, 2019, 8:34:05 AM12/12/19
to puppe...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages