Template:FAQ:Agent 24

The idea behind the new access control model is to give a more flexible way of specifying who can see and do what within the MIB tree. It's more complicated to understand than the simple example above, but that's because it can do a whole lot more.

There are four configuration keywords in the new scheme:

       'com2sec', 'group', 'view', and 'access'

We'll consider these one at a time, starting with 'access'. (Because I feel like starting with the last one, that's why - OK?)

The "access" keyword has the job of specifying who has access to which bits of the MIB tree. This has eight parameters, so can look rather offputting. Most of these can be safely left with default values in most cases (so don't you worry your pretty little head about them). The syntax is

       access {group} "" any noauth exact {read-tree} {write-tree} {notify-tree}

where the entries in braces need to be defined elsewhere (I'm coming to that - be patient!), and the rest can be left as shown here.

[If you really want to know, the 'sec.model' field can be used to have an access line that's only relevant to specific versions of SNMP (such v1 or v2c) rather than "any" version, and the 'sec.level' field to ensure that the request must be authenticated or encrypted. The context and prefix fields can be used to distinguish between parallel versions of the same overall OID tree]

The "view" keyword is used to define particular bits of the MIB tree, for use in the last three fields of the access entry. This has the syntax

       view  {name}  included/excluded  {subtree}   {mask}

where {name} is the identifier to be used for this view (i.e. what should appear in the access entry), and {subtree} is the portion of the MIB tree that this name refers to (in either numeric or named form). Note that the name of the view does not have to have anything to do with the MIB sub-identifier names - it's purely an identifying tag for use within the config file (though choosing a meaningful name is, as always, a very good idea).

The {mask} field can be used to control which elements of the OID subtree should be regarded as relevant when determining which view an OID is in. This is most relevant when defining "unusual" views, such as a single row of a table. In most cases, this field should be omitted.

The third field can be used to include or exclude particular portions of the MIB from the named view. A single view can be built up using several 'view' lines (with the same view name), including or excluding OID subtrees as appropriate.

The three view fields in the access line are used to control which portions of the MIB tree a particular {group} can see (GET et al), alter (SET), or request NOTIFYs on.

That's dealt with the "what" - now for the "who". This is the role of the "group" and "com2sec" entries.

The "group" keyword gives general control, by mapping between a "security name" (for a particular protocol version), and the internal name used in the access line. Note that the token "any" is no longer acceptable for the security model - the original support for this was due due to a misreading of the RFC. You should replace any such line with separate versions for each of the desired security models ('v1', 'v2c' & 'usm').

For SNMPv1 and SNMPv2c, the group line is just an intermediate step between the "access" line and the "com2sec" line, which is the last bit of the jigsaw. The "com2sec" entry is used to determine a "security name" from the traditional community string, taking into account where the request has come from. Thus the same community string can give access to different portions of the tree, depending on where the request is sent from.

For example, in an earlier version of the example config file, there were two com2sec lines with the community string "public" - one was valid from anywhere (with the security name "public") and one was only valid from the local network (using the security name "mynet"). The group lines converted these security names into the groups "public" and "mygroup" respectively, and the access lines gave these two groups the ability to GET values in the 'system' sub-tree (from anywhere) or the 'mib-2' sub-tree (from the local network). Neither of these could SET any values though, (since the write-tree was "none" in both cases). Someone on the local machine, using the community string "private", had the security name "local" and the group name "local", and hence had full access (both GET and SET, as well as NOTIFY) to the whole of the MIB tree (or at least everything under .1, which covers most things!)

Note that the three occurrences of "public", as community string, security name and group name, were three totally separate things. You can't use a community string in a security name field, or either of these as a group name (or vice versa), unless you set up suitable entries to map one name onto the other.

With SNMPv3, the security name is part of the basic protocol (or near enough), and can be used directly in a group definition.

And here concludes our tour of the view-based access control mechanism. Phew!