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:

Name:     bob
EPasswd:  $2a$10$sck5WIOLGsthgyX
Home:     Top
Groups:   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:

  1. acl_user
  2. acl_staff
  3. 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