The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Feature #4607

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

Added by Nigel Kersten over 3 years ago. Updated about 1 month ago.

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

0%

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

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket is now tracked at: https://tickets.puppetlabs.com/browse/PUP-1727


Description

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.

History

#1 Updated by James Turnbull over 3 years ago

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

#2 Updated by Clay Caviness about 3 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 about 2 years ago

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

#4 Updated by Gary Larizza over 1 year ago

  • Assignee deleted (Gary Larizza)

#5 Updated by Jesse Endahl about 1 year ago

Just figured I’d post to say I recently ran into this when trying to make the admin group a member of the com.apple.access_ssh 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 com.apple.access_ssh && dseditgroup -o edit -a 'admin' -t group com.apple.access_ssh",
      }

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

See: http://projects.puppetlabs.com/issues/9337#note-9

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 1 month ago

Redmine Issue #4607 has been migrated to JIRA:

https://tickets.puppetlabs.com/browse/PUP-1727

Also available in: Atom PDF