The Puppet Labs Issue Tracker has Moved:

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using See the following page for information on filing tickets with JIRA:

Feature #4607

directoryservice group provider for OS X should allow groups to be members of a group

Added by Nigel Kersten over 5 years ago. Updated about 2 years ago.

Status:AcceptedStart date:08/25/2010
Priority:NormalDue date:
Assignee:-% Done:


Target version:-
Affected Puppet version: Branch:
Keywords:group, os x

We've Moved!

Ticket tracking is now hosted in JIRA:

This ticket is now tracked at:


Unlike many other systems, OS X considers group membership to be an attribute of the group, not the members, and so we have a situation where in Puppet the provider can manage group membership.

It turns out that we can only manage users as members of this group, but it’s perfectly valid to have nested groups in OS X.

We should support this.

This came up because of someone wanting to use the Puppet group type to manage Service ACLs in OS X, which are simply groups with a specific naming scheme. The vast majority of the time when you wish to do this, you want to nest groups inside the SACL.

There are a few unanswered questions about how we’d do this, as the provider simply doesn’t know whether a given string refers to a user or a group, and it needs to execute different commands in each scenario.

We also don’t really want to have to supply Puppet resource references, as some of these groups may be in a remote directoryservice node, and thus unsuitable for being managed by Puppet.

Perhaps we have another ‘group_members’ attribute? Then we need to work out whether something is a group or a user when checking status…

Anyway, while it’s not clear how best to do this, I think it’s something we should do.


#1 Updated by James Turnbull over 5 years ago

  • Category set to OSX
  • Status changed from Unreviewed to Accepted

#2 Updated by Clay Caviness about 5 years ago

I’m doing this now with some typically ugly execs:

exec { "add_somenestedgroup_to_somegroup":
  path    => "/usr/sbin:/usr/bin",
  command => "dseditgroup -o edit -n . -t group -a somenestedgroup somegroup",
  unless  => "dseditgroup -o read somegroup 2>&1 | grep $(dsmemberutil getuuid -G somenestedgroup)",

.. but it would all be much nicer to manage this in a group resource.

#3 Updated by Gary Larizza over 4 years ago

  • Assignee set to Gary Larizza
  • Keywords set to group, os x

#4 Updated by Gary Larizza almost 4 years ago

  • Assignee deleted (Gary Larizza)

#5 Updated by Jesse Endahl about 3 years ago

Just figured I’d post to say I recently ran into this when trying to make the admin group a member of the group (which I think is probably a pretty common use-case). Ended up doing this to work around it:

exec { "ssh for admin users only":
        path   => ['/usr/sbin'],
        command   =>  "dseditgroup -o create -q && dseditgroup -o edit -a 'admin' -t group",

But exec makes me sad =)

FWIW, it looks like this has been a known issue since September 2011: “Note another thing we don’t support is the fact OS X can support nested groups, where groups are members of groups.” — Nigel Kersten


Edit: Just realized this bug report is actually older than the comment I linked to. Anyway, I am extremely willing to assist with testing if/when that’s needed.

#6 Updated by Jesse Endahl about 2 years ago

Redmine Issue #4607 has been migrated to JIRA:

Also available in: Atom PDF