Implications of manually adding a user to the staff group

by R.S.   Last Updated July 05, 2018 19:02 PM

This came up as a permission issue on Ubuntu 16.04. I was unable to remove some R libraries installed in /usr/local/lib/R/site-library. It turned out that I did not have permission. The directory was owned by root and the group was staff.

I temporarily resolved the permission issue by manually adding my user to the staff group.

sudo usermod -a -G staff myusername    

# *see blockquote before using this!* 

That allows me to remove the libraries from IDE.

However, when I tried to look up more information on staff group and was not able to find any definite material on the topic. Not even what the group was primarily intended for. I could only guess it is used to give similar 'enhanced' access to users on certain directories.

Are there any implications of manually adding a user to the staff group?

As an aside, is there any command to know the system-wide permissions for a group? For instance, what all are the directories for which group staff will have write permission?


Edit: I must add here that using adduser instead of usermod is a much more sensible option for this operation [please see the comment below]

sudo adduser myusername staff

Answers 1

Ok, as nudged by @muru, I'm posting an answer to my own question, to the extent I can. The file file:///usr/share/doc/base-passwd/users-and-groups.html includes detailed information on groups and permissions. A mirror of this page can be found here: Users and Groups



Allows users to add local modifications to the system (/usr/local, /home) without needing root privileges. Compare with group adm, which is more related to monitoring/security.

Note that the ability to modify /usr/local is effectively equivalent to root access (since /usr/local is intentionally on search paths ahead of /usr), and so you should only add trusted users to this group. Be careful in environments using NFS since acquiring another non-root user's privileges is often easier in such environments.

Of course adm is already in my groups so I can do dmesg. But I had to manually add myself to staff

Logging a list of directories owned by staff shows that all these belong to one of these:

sudo find / -maxdepth 8 -type d -group staff -perm -g=w >>stafflog.txt


No wonder the membership of staff gives me write access to my shared programming language libraries.

checking permission for one of these:

ls -al /var/local

drwxrwsr-x  2 root staff 4096 Apr 11  2014 .
drwxr-xr-x 16 root root  4096 Aug  3 15:55 ..

So apparently the staff trick is performed by the system by setting the directories' s bit (setguid). , so that whichever user or process creates the files in that directory, the file always runs with the permissions shared across the staff group. See here

However I still wonder whether I can safely keep myself in this group. To my mind it should be pretty safe given this is a laptop which will at worst be accessed over a trusted LAN, via smb or ssh. The words 'effectively equivalent to root access' scare me. Any thoughts on this are welcome.

October 07, 2016 10:13 AM

Related Questions

Relationship between file/folder's owner and group?

Updated September 15, 2015 06:01 AM

Permission access for folder to group

Updated December 12, 2017 12:02 PM

Can I define a parent group and children groups?

Updated October 05, 2018 17:02 PM

Member of group cannot cd into directory

Updated March 11, 2018 13:02 PM