security groups - Revision history

Woozle: slight tidying & update

2018-01-05T20:02:53Z

slight tidying & update

← Older revision		Revision as of 20:02, 5 January 2018
Line 1:		Line 1:
	~~[[Computing]]: [[Computing Concepts\|Concepts]]: [[User-Group~~ Security~~]]: [[security~~ groups~~\|Groups]]~~		'''Security groups''', also referred to as "roles", are basic concept in multiuser software design.

	~~[[Groups]]~~, also ~~known~~ as "~~Roles~~", are ~~an essential~~ concept in ~~[[User-Group Security]]. It is a common solution to the problem of any multi-user system where some users must have access to certain features while other users do not~~.

	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.		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.
Line 17:		Line 15:
	* '''admin''', '''sysadmin''', or '''sysop''': highly trusted individual with access to administration functions but not necessarily to everything		* '''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!").		* '''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!").
			==Related==
			* [[Linux/groups]]: the way this is implemented in Linux-like systems

Woozle: Woozle moved page Security groups to security groups without leaving a redirect: not the name of a thing, just a concept

2018-01-05T20:00:08Z

Woozle moved page Security groups to security groups without leaving a redirect: not the name of a thing, just a concept

← Older revision	Revision as of 20:00, 5 January 2018
(No difference)

Woozle at 15:11, 2 November 2005

2005-11-02T15:11:11Z

New page

[[Computing]]: [[Computing Concepts|Concepts]]: [[User-Group Security]]: [[security groups|Groups]]

[[Groups]], also known as "Roles", are an essential concept in [[User-Group Security]]. It is a common solution to the problem of any multi-user system where some users must have access to certain features while other users do not.

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)
* [[security users|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.
==Common Roles==
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!").