# The group "staff"



## twilight (Dec 8, 2009)

Dear Community,

I finally found my way to FreeBSD and want to use it as a server-system, and maybe for the one or other desktop.

Having that said: I come from Gentoo-Linux, so I am quite experienced with compiling software on my own, and then found my way over to MacOS X.

In MacOS X 10.4 every user had his own group. 10.3 and before, there was the group "staff", and in 10.5 the group staff was re-introduced.

A friend of mine brought me to FreeBSD about 10 years ago, but I guess I was not ready. Now, with FreeBSD 8.0 I am sort of coming back.

*So my question is*: When I create a user, per default he gets a new group with his own name, and is NOT part of the group "staff". Is that new to FreeBSD 8.0, because I thought, that every user is member of staff.

Why is staff unused? And is it wise to edit /etc/adduser.conf to always use "staff" as the standard-group for new users?

Maybe my question is stupid because it has been answered in the handbook already, but I could not find anything (google, handbook). That's why I ask here, hence I know how it works with (Gentoo)-Linux, how it works differently in the different versions of MacOS and I thought I knew it how it works in FreeBSD as well, but aperantly, I was wrong ;-)

Thanks for any hints!

Thomas


----------



## SirDice (Dec 8, 2009)

twilight said:
			
		

> *So my question is*: When I create a user, per default he gets a new group with his own name, and is NOT part of the group "staff". Is that new to FreeBSD 8.0, because I thought, that every user is member of staff.


Nope, it's that way ever since I can remember (that'll be the 3.x days). 



> Why is staff unused?


It's a relic from the past. I've only seen "staff" being used on OS-X. And even there you shouldn't use it.



> And is it wise to edit /etc/adduser.conf to always use "staff" as the standard-group for new users?


No.


----------



## twilight (Dec 8, 2009)

thanks for such a quick answer.

Well, if it should not be used I wonder why apple did not use it,
then used it in 10.4 and then re-shifted to use it in 10.5 and 10.6.

Anyhow, I'll leave it as it is then, thanks!


----------



## twilight (Dec 8, 2009)

sorry, did not find the "edit"-button:

...wonder why apple used staff, did not use it in 10.4 and now is using it again with 10.5+...


----------



## SirDice (Dec 8, 2009)

twilight said:
			
		

> sorry, did not find the "edit"-button:


You can edit your own posts after 10 



> ...wonder why apple used staff, did not use it in 10.4 and now is using it again with 10.5+...


If I'm not mistaken the first user that's made during the initial setup uses the same name for both a group and the username. It's not really obvious until you try to change your username (as I've done).

Subsequent users seem to be put into staff but that's probably because it's the first one in the list of the GUI. I don't have OS-X at hand now but I'm quite sure you can create a named group along with the user. To be honest OS-X looks and feels like a dumbed down version of *nix. The admin group is pretty much the only group you need to worry about. Every member of that group automatically has full sudo access. That group can also write in quite a few directories.


----------



## twilight (Dec 8, 2009)

We have several Macs and Mac-Servers here in our company, as we are an AppleAuthorizedServiceProvider.

When I "id username" any user on different machines, every user has as primary group always 20 (which is staff).
This is true except for 10.4 (Tiger).

I find it absolutely beneficial to have a group that contains all users. If that has to be the primary group or not is another question.

Since OS-X has part FreeBSD-heritage I wonder why they would use staff when FreeBSD does not.

Can you be more specific why I should not use it?

Any info how this is handled with other *BSD-Systems such as NetBSD or OpenBSD?


----------



## twilight (Dec 8, 2009)

twilight said:
			
		

> This is true except for 10.4 (Tiger).



On Tiger every user has his own group, which is named identical to the username.


----------



## SirDice (Dec 8, 2009)

twilight said:
			
		

> I find it absolutely beneficial to have a group that contains all users.


Create a group called "users".



> Since OS-X has part FreeBSD-heritage I wonder why they would use staff when FreeBSD does not.


I think Apple would be the one to answer that.


----------



## SirDice (Dec 8, 2009)

twilight said:
			
		

> Can you be more specific why I should not use it?


Here's one reason:


```
drwxrwxr-x   3 dice  staff   102 Sep  5 14:20 Trapcode Particular2 Uninstaller.app
```

This is in /Applications. It's a relic from where I screwed up with my accounts. As you can see the staff group has write access there. This means that _any_ member of the staff group has write access there. Not the sort of thing you want in /Applications.


----------



## twilight (Dec 8, 2009)

/Applications, is this a folder you created on your FreeBSD_System? Because I don't have it here and only know it from OS-X.

On OS-X staff does have no rights besides reading and executing in /Applications, hence the *.app-Applications are owned by u:root and g:admin or u:root and g:wheel.


----------



## SirDice (Dec 8, 2009)

twilight said:
			
		

> /Applications, is this a folder you created on your FreeBSD_System? Because I don't have it here and only know it from OS-X.


Yes, that's on OS-X.




> On OS-X staff does have no rights besides reading and executing in /Applications, hence the *.app-Applications are owned by u:root and g:admin or u:root and g:wheel.


Well, the installer did set the permissions like that. Obviously not my choice


----------



## twilight (Dec 8, 2009)

SirDice said:
			
		

> Well, the installer did set the permissions like that. Obviously not my choice



But that is an installer-problem I would guess. I've seen that on OS-x, too, that an installer used "staff" instead of "wheel" or "admin" as it should. Using "staff" is not the fault of the group staff but the installing users primary group is being used in some faulty installers.

That problem would be the same when every user had his own group, so I still don't get why I should create a special group "users" instead of using "staff" which is already there?

Sorry for keeping asking, but I really like to understand things and not just accept them. ;-)

Thanks for your patience!!


----------



## SirDice (Dec 8, 2009)

twilight said:
			
		

> But that is an installer-problem I would guess. I've seen that on OS-x, too, that an installer used "staff" instead of "wheel" or "admin" as it should. Using "staff" is not the fault of the group staff but the installing users primary group is being used in some faulty installers.
> 
> That problem would be the same when every user had his own group, so I still don't get why I should create a special group "users" instead of using "staff" which is already there?


Because of the above problem. If the installer uses the primary group of the user installing it everyone would be able to write in that directory (because everyone's primary group is staff). So you set the primary group to the same name as the username. Then noone else can write there even if you have a b0rked installer.


----------



## twilight (Dec 8, 2009)

so what you are actually recommending for my FreeBSD ist:

create every user with its own group, and use "users" as a second group.

Or something else against using "staff" as a secondary group for the users?


----------



## SirDice (Dec 8, 2009)

twilight said:
			
		

> so what you are actually recommending for my FreeBSD ist:
> 
> create every user with its own group, and use "users" as a second group.


Yes, and I recommend it on OS-X too 



> Or something else against using "staff" as a secondary group for the users?


AFAIK on OpenBSD the staff group has some extra privileges.


----------



## twilight (Dec 8, 2009)

> AFAIK on OpenBSD the staff group has some extra privileges.



but not on FreeBSD?


----------



## DutchDaemon (Dec 8, 2009)

As far as I can see the 'staff' group has no elevated privileges and is merely a way of organising accounts. It could just as well have been called 'sysops', 'admins', or 'techs'.


----------

