Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-9465

group resource type misunderstands/misuses libuser



    • Night's Watch
    • 5
    • NW - 2019-08-21, NW - 2019-09-03, NW - 2019-09-18, NW - 2019-10-02, NW - 2019-10-16, NW - 2019-10-30, NW - 2019-11-13, 2019-11-27, 2019-12-11, 2019-12-24, NW - 2020-01-22, NW - 2020-02-05, NW - 2020-02-19
    • New Feature
    • The `groupadd` provider can now manage members using the `members` resource parameter.
    • Needs Assessment


      Puppet Version: 6.1.0
      Puppet Server Version: 6.1.0
      OS Name/Version: Red Hat Enterprise Linux 7

      The group resource type supports the groupadd provider, but not the lgroupadd provider.

      lgroupadd (and lgroupmod and lgroupdel) are part of the libuser library/package. While libuser is essentially a rewrite of the groupadd, groupmod, and groupdel programs from the shadow-utils package (because Red Hat tends toward NIH syndrome), lgroupmod has one important advantage over groupmod: lgroupmod can manipulate group members directly.

      E.g., you can do this:

      $ lgroupmod --member-add user1,user2,user3 somegroup

      In contrast, groupmod cannot do this. Instead, you have to do this:

      $ usermod -a -G somegroup user1
      $ usermod -a -G somegroup user2
      $ usermod -a -G somegroup user3

      This is why the groupadd provider for the group resource type lacks the manages_members feature.

      The implication of this is that in Puppet, if you want to have a class manage the contents of a group, the only way to do it (using default resource types) is to manage user resources for each user who should be a member of the group. But this doesn't scale, because if any other module is attempting to manage a user resource type for the same user, the resources will clash.

      In contrast, if support were added for the lgroupadd provider, the manages_members feature could be enabled for it. This would permit managing the membership of an arbitrary group by managing a single group resource for the group, instead of managing individual user resources.

      Granted, this could create the state where a Puppet user resource using the useradd provider could "fight" with a Puppet group resource using the lgroupadd provider. But this potential for conflict already exists in other places in Puppet (e.g., augeas resources can cheerfully fight with file resources). So I don't think the potential for conflict is a reason to avoid adding the lgroupadd provider.

      So, in summary, I think Puppet should add support for the lgroupadd provider (and company) for the group resource type on platforms where the libuser library/package is available: Fedora, Red Hat, CentOS, and potentially others.

      Yay or nay?

      (I may be able to work on adding this provider myself, but I don't want to spend the time on a merge request if Puppet is philosophically opposed to adding support for the lgroupadd provider.)


        Issue Links



              gabriel.nagy Gabriel Nagy
              ralston James Ralston
              0 Vote for this issue
              5 Start watching this issue



                Zendesk Support