Access Control

In the users section we saw how to make a user a member of a set of groups. In order to control access to things, we specify which groups have access to a particular thing. If the user is a member of any of the specified groups, access is permitted.

say we have a users file entry:

	bob	xxYeIExOhgQJU	Top	gibber jabber

bob now belongs to both the 'gibber' and 'jabber' groups.

	Group "Foo" {
		acl_foobar:	jabber gizzle
		...
	}

this gives all members of the groups 'jibber' and 'gizzle' foobar permission. Thus, the user bob, being a member of 'jabber', has foobar access.

In most installations, the default access control lists are sufficient, and you will not need to specify anything further.

Specifying Access Control Lists

You can specify access control parameters on an object in either of 2 modes: simple or extended.

In simple mode, there are 3 access control lists which control all permissions:

acl_user
acl_staff
acl_root

acl_user controls basic read access to an objects webpage. acl_staff controls some read-write access, such as setting or removing overrides, and acknowledging notifications. acl_root controls everything else, such as accessing debug info, and the configuration data.

Note, these are separate acls, controlling access to different things. Argus will happily permit a user access to debugging info (acl_root) and deny them access to view the webpage (acl_user). If you want to permit a user access to everything, they will need to be in all 3 of the acls.

Simple Mode Defaults

By default, if no acls are specified in the config file, argus uses 3 groups named 'user', 'staff', and 'root' and creates acls:

	acl_root:	root
	acl_staff:	staff root
	acl_user:	user staff root

allowing you to assign one of these 3 groups to users in the users file

Extended Mode

In extended mode, each separate function has its own acl.

	Group "Foo" {
		acl_mode:	extended
		acl_override:	staff
		acl_getconf:	sr_staff
		...
	}

The acls are:

acl_page
acl_getconf
acl_about
acl_flush
acl_override
acl_annotate
acl_logfile
acl_ntfylist
acl_ntfyack
acl_ntfyackall
acl_ntfydetail

In versions 3.5 and later, the acl_mode no longer needs to be specified, and simple mode and extended mode parameters may be mixed and matched.

Cumulative Inheritance

ACLs are cumulative from the top level down.

	Group "Foo" {
		acl_override:	foo

		Group "Bar" {
			acl_override:	bar
			...
		}
	}

Members of both groups 'foo' and 'bar' will have override access on 'Bar'.

The syntax '-group' can be used to remove groups. The special '-ALL' will remove all groups:

	Group "Foo" {
		acl_override:	foo bar
		Group "Bar" {
			acl_override:	-foo baz
			...
		}
		Group "Baz" {
			acl_override:	-ALL baz
			...
		}
	}