21

It's known that all users are members of the 'staff' group. If you setup a standard user and create any file, a list of that file in the terminal with 'ls -la' shows the user group to be 'staff'.

Using the dscacheutil command, we can see information about groups. For example: -

dscacheutil -q group -a name admin

This returns information about the admin group, including all the members.

However, when used to look at the 'staff' group, I expected to see standard users as members of the group, but this is not the case: -

dscacheutil -q group -a name staff

name: staff
password: *
gid: 20
users: root

So, if all standard users are members in the staff group, why do they not appear here?

Is there another command which can show the real members of the staff group?

  • 3
    Great question. I'll probably want to bounty this if it doesn't get enough attention. I was thinking it was somehow coded to only show the primary group members, but all my named users (above hid 500) are all primary group as staff and still not listed by the cache util as in the group (where oddly root with GID of wheel is listed...) Odd sauce indeed... – bmike May 14 '14 at 14:32
  • Thanks @bmike, interestingly, the same can be seen in the Directory Utility app, which is in /System/Library/CoreServices. – TheDarkKnight May 14 '14 at 14:42
  • Oh I thought that only root was a member of staff. Like /etc/group shows: staff:*:20:root – Scott Walter May 14 '14 at 15:58
  • @ScottWalter, admin users are members of 'staff' and 'admin' while non-admin are members of only the 'staff' group. See the section "Owner, group, Others" here: support.apple.com/kb/HT2963 – TheDarkKnight May 14 '14 at 16:03
  • Also see Repair disk permissions with Disk Utility. – jww Sep 7 '18 at 18:25
9

There's only one reliable way to get all members of a group in OS X and the reply from 2DD8847 covers that. As for "why" I can't offer a logical explanation. All I can tell you is what differentiates the results.

These approaches fail to include users that are only members of the group via PrimaryGroupID. One way to think of it is that these users not listed weren't officially added to the staff group. They were just given a PrimaryGroupID that matches the staff gid. Therefore they're not officially listed with some commands. I know, it's absurd.

INCOMPLETE RESULTS:

dscl . -read /Groups/[groupname]
dscl . -read /Groups/[groupname] GroupMembership
dscacheutil -q group -a name [groupname]

COMPLETE RESULTS:

dscl . -list /Users PrimaryGroupID | grep [gid]

All I can really tell you is that without looking up group members by their PrimaryGroupID (instead of listing members of a group) it won't give you complete results. Chalk it up to the oddities of Unix. There are many.

Hope that helps!

Source

  • "these users not listed weren't officially added to the staff group. They were just given a PrimaryGroupID that matches the staff gid" - Now that makes sense. I wonder if there's a valid security attack vector with this; if it's possible to set a user's PrimaryGroupId without actually adding them to the admin group, would that give them admin rights? I shall investigate. – TheDarkKnight May 15 '14 at 9:07
  • I didn't mean to suggest anything is wrong. Don't worry, staff members do not have admin rights on your machine. In OS X almost everything has the owner set to staff, but remember that other permissions override the misuse of this reality. Every user folder is "readable" by every other user, but inside every user folder you'll see individual item is set to have read access revoked. So /Users/username/Desktop has user everyone set to No Access - It's not clean permission management, but it works and you're secure. – sgelliott May 15 '14 at 17:13
  • 4
    Maybe you meant Chalk it up to the oddities of OS X. There are many. – user3019105 Mar 12 '16 at 22:17
  • i was looking at a disc from another machine and yeah, the usernames get renamed, i became "steve" as user 502 or maybe 501. anyhow. my theory is that "staff" should probably have been called "macosx" and it's used by the Finder to do "rooty" stuff on the regular users behalf. just a random theory. – Tomachi Sep 24 '18 at 8:26
  • 1
    @Tomachi staff could not be macosx it was set up any years before OsX when the system was NeXT – Mark Nov 19 '18 at 14:32
4

What exactly do you want to achieve/do?

This command lists all users in the staff group:

dscl . -list /Users PrimaryGroupID | grep ' 20$'

Source

Explanation: The staff group has the PrimaryGroupID of 20.

  • I'm trying to understand why the staff group doesn't show its member list via dscacheutil and the Directory Utility. My main goal is to retrieve the list of members from a group using C++, without calling a separate process. During this process, I came across the issue of the group not displaying its members and I want to know why this is the case. – TheDarkKnight May 14 '14 at 15:43
  • Why dscacheutil doesn't list the staff group...i don't know. developer.apple.com/library/mac/documentation/Darwin/Reference/… It's an implementation, and somehow they decided not to show them. – Bastian Gruber May 14 '14 at 15:47
  • 2
    Sorry, but saying "it's an implementation" and linking to the man pages of dscacheutil does not answer the question. – TheDarkKnight May 14 '14 at 15:49
  • For C++, you can call a shell function. I found this site very helpful: blog.earth-works.com/2012/09/13/… I don't think there is any reason why they don't show it. They built a function and you are missing something..what should i say. They prevent you from showing you the members because they like it? – Bastian Gruber May 14 '14 at 15:50
  • 2
    Calling a shell function spawns a separate process. For various reasons, this is not viable for the project I'm working on. I'm now looking at the Identity Services: developer.apple.com/library/mac/documentation/networking/… – TheDarkKnight May 14 '14 at 15:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .