Security groups, also referred to as "roles", are basic concept in multiuser software design.
The obvious solution is to maintain a list of features to which access must be controlled, and a list of which users are allowed to access (i.e. given "permissions" or security rights for) each feature. This solution can get complicated, however, when users need to be given additional access, or when they stop working on a particular task and no longer need access to the same things. Where the needed features for one task overlap with those for another task, it is easy to make mistakes and take away too many permissions, or give the wrong ones.
This is where the concept of "groups" becomes very useful, because the needed set of security rights is almost always defined by which system-related tasks or jobs the user is doing. Rather than giving the user each security right individually:
- a set of "roles" or security groups are defined, based on the known jobs or tasks which need to be done
- then the security rights needed to do each of those jobs are assigned to the appropriate group(s)
- users who are doing those jobs are given membership in the corresponding group(s)
The system then gives each user permissions to access any feature allowed by any of their group memberships; in other words, as long as at least one of their job roles requires a certain feature, they will have access to it – but if none of their job roles requires a particular feature, they are not given access to it.
Any user has at least one "role" to play if they are going to interact with a system, even if that role is to be "anonymous" or a "guest" user unknown to the system. Roles common to many systems include:
- anonymous or guest: this person is unknown to the system, and should not be trusted with any features which could be used to damage the system
- webmaster: this is a web-server specific role. This user has access to an account on the web server, which usually allows transferring files to/from the server, installation of scripts, and sometimes access to a command-line prompt. This role usually does not have access to server administration functions.
- admin, sysadmin, or sysop: highly trusted individual with access to administration functions but not necessarily to everything
- root (in Linux) or superuser: This user is "god" on the system and can do anything they want. Most security systems try to severely limit the number of root users, although more than one may be necessary in order to provide redundancy ("Jane is out of town on vacation and we need to restart the server!").
- Linux/groups: the way this is implemented in Linux-like systems