Implications of manually adding a user to the staff group

Solution 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

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.