Implications of manually adding a user to the staff group

Question

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?

Thanks.

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

Solution

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

Accordingly:

staff

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

/var/local
/usr/local/lib
/usr/local/share

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.

Comments

[muru]

For the last question, sudo find / -type d -group staff -perm -g=w (not counting permissions set by ACLs)

[muru]

Also, there might be some information in /usr/share/doc/base-passwd/users-and-groups.txt.gz, but I don't an Ubuntu system on hand to check. And it's easier to use adduser for adding to a group: sudo adduser myusername staff, less chances of screwing up if you forget -a.

[R.S.]

@muru. Thanks. That pointed me in the right direction. I hqven't extracetd that gzip file yet, but the html file in that dir -- /usr/share/doc/base-passwd/users-and-groups.html has much of the information I was looking for. If noone else chips in with anything significantly informative, I'd be happy to accept it as an answer. That might need some embellishment for sake of future readers though, I reckon.

[R.S.]

As for find, I'd already done that and dumped to a log. Will need some parsing and pruning to make sense of it. Was wondering if there was a utility specifically for that. Setting -maxdepth 2 shows whole of /local/ is owned by staff.

[muru]

Ah, it might be better if you wrote the answer, since you have the information on hand. :)

[R.S.]

ok. I guess I better follow that :-)

[mook765]

In doubt you can remove yourself from the staff-group. sudo deluser username staff. You don't need to be in this group, you are in the sudoers-group and always able to do anything, it just requires to enter the password.

[R.S.]

yeah, but this way I can do some of this stuff right from the IDEs. I usually keep all the libraries under ~ but while upgrading UBUNTU , it took the liberty of installing all sort of stuff in the default locations. Now I run into these surprise conflicts from time to time. Have removed myself from the group to be on the safe side, though .

[Rolf]

I don't get it; "the ability to modify /usr/local is effectively equivalent to root access" yet any file inside /var/local supposedly has this ability?