SNMPVACM(1)
πΈ SNMPVACM πΈ
okay bestie, gather round, because this is the Net-SNMP manual page for snmpvacm(1) and it's literally the tool that does SNMPv3 View-based Access Control β¨
β¨ NAME β¨
snmpvacm β creates and maintains SNMPv3 View-based Access Control entries on a network entity π
π¦ SYNOPSIS π¦
snmpvacm [COMMON OPTIONS] AGENT createSec2Group MODEL SECURITYNAME
GROUPNAME
snmpvacm [COMMON OPTIONS] AGENT deleteSec2Group MODEL SECURITYNAME
snmpvacm [COMMON OPTIONS] AGENT createView [-Ce] NAME SUBTREE MASK
snmpvacm [COMMON OPTIONS] AGENT deleteView NAME SUBTREE
snmpvacm [COMMON OPTIONS] AGENT createAccess GROUPNAME [CONTEXTPREFIX]
MODEL LEVEL CONTEXTMATCH READVIEW WRITEVIEW NOTIFYVIEW
snmpvacm [COMMON OPTIONS] AGENT deleteAccess GROUPNAME [CONTEXTPREFIX]
MODEL LEVEL
snmpvacm [COMMON OPTIONS] AGENT createAuth GROUPNAME [CONTEXTPREFIX]
MODEL LEVEL AUTHTYPE CONTEXTMATCH VIEW
snmpvacm [COMMON OPTIONS] AGENT deleteAuth GROUPNAME [CONTEXTPREFIX]
MODEL LEVEL AUTHTYPE
π DESCRIPTION π
So snmpvacm is an SNMP application, and its whole thing is doing simple maintenance on the View-based Control Module (VACM) tables of an SNMP agent. no cap. π«Ά
The SNMPv3 VACM specs (peep RFC2575) define a bunch of assorted tables that specify groups of users, MIB views, and authorised access settings. Every snmpvacm command you run is lowkey just creating or deleting rows in the appropriate one of those tables, and it matches up with the equivalent configure directives documented over in the snmpd.conf(5) man page. π
A fuller explanation of how these operate can be found in the project FAQ. (yes, go read it, it's giving study guide π)
π SUB-COMMANDS π
π createSec2Group MODEL SECURITYNAME GROUPNAME
Create an entry in the SNMPv3 security name to group table. This table is the moment where a single access control entry can be applied to a whole bunch of users (or 'principals'), and it's indexed by the security model and security name values. iconic behaviour honestly.
MODELβ an integer representing the security model, and it takes one of these values:1- reserved for SNMPv12- reserved for SNMPv2c3- User-based Security Model (USM)
SECURITYNAMEβ a string representing the security name for a principal (and it's represented in a security-model-independent format, fancy β¨). For USM-based requests, the security name is the same as the username. iykyk.GROUPNAMEβ a string identifying the group that this entry (i.e. the security name/model pair) should belong to. This group name is what then gets referenced in the access table (seecreateAccessbelow). π«‘
π deleteSec2Group MODEL SECURITYNAME
Delete an entry from the SNMPv3 security name to group table, which removes the access control settings for the given principal. the way that this entry is indexed by the MODEL and SECURITYNAME values... and those should match the ones you used in the corresponding createSec2Group command (or equivalent). don't be messy about it π
π« createView [-Ce] NAME SUBTREE MASK
Create an entry in the SNMPv3 MIB view table. A MIB view is literally a family of view subtrees, and each one can be individually included in or (occasionally) excluded from the view. Every view subtree is defined by a combination of an OID subtree together with a bit string mask. The view table is indexed by the view name and subtree OID values. πΈ
-Ceβ an optional flag to indicate that this view subtree should be excluded from the named view. If you don't specify it, the default is to include the subtree in the view. When you're constructing a view from a mixture of included and excluded subtrees, the excluded subtrees should be defined first β especially if the named view is already referenced in one or more access entries. order matters bestie πNAMEβ a string identifying a particular MIB view, of which this OID subtree/mask forms part (possibly the only part, ngl).SUBTREEβ the OID defining the root of the subtree to add to (or exclude from) the named view.MASKβ a bit mask indicating which sub-identifiers of the associated subtree OID should be regarded as significant. β¨
π¦ deleteView NAME SUBTREE
Delete an entry from the SNMPv3 view table, which removes the subtree from the given MIB view. Heads up: removing the final (or only) subtree will result in the deletion of the view. π The entry to be removed is indexed by the NAME and SUBTREE values, and those should match the ones used in the corresponding createView command (or equivalent).
When removing subtrees from a mixed view (i.e. one containing both included and excluded subtrees), the included subtrees should be removed first. yes, the reverse of the create order. it's giving plot twist π
β createAccess GROUPNAME [CONTEXTPREFIX] MODEL LEVEL CONTEXTMATCH READVIEW WRITEVIEW NOTIFYVIEW
Create an entry in the SNMPv3 access table, which allows a certain level of access to particular MIB views for the principals in the specified group (given suitable security model and levels in the request). The access table is indexed by the group name, context prefix, security model and security level values. main character energy fr fr π
GROUPNAMEβ the name of the group that this access entry applies to (as set up by acreateSec2Groupcommand, or equivalent).CONTEXTPREFIXβ a string representing a context name (or collection of context names) which this access entry applies to. The interpretation of this string depends on the value of theCONTEXTMATCHfield (see below, bestie π).- If omitted, this will default to the null context
"".
- If omitted, this will default to the null context
MODELβ an integer representing the security model, taking one of the following values:1- reserved for SNMPv12- reserved for SNMPv2c3- User-based Security Model (USM)
LEVELβ an integer representing the minimal security level, taking one of the following values:1- noAuthNoPriv2- authNoPriv3- authPriv
This access entry will be applied to requests of this level or higher (where authPriv is higher than authNoPriv which is in turn higher than noAuthNoPriv). it's a ladder and you're climbing it πͺ
CONTEXTMATCHβ indicates how to interpret theCONTEXTPREFIXvalue. If this field has the value1(representing 'exact') then the context name of a request must match theCONTEXTPREFIXvalue exactly for this access entry to be applicable to that request.- If this field has the value
2(representing 'prefix') then the initial substring of the context name of a request must match theCONTEXTPREFIXvalue for this access entry to be applicable to that request. This provides a simple form of wildcarding. β¨
- If this field has the value
READVIEWβ the name of the MIB view (as set up bycreateViewor equivalent) defining the MIB objects for which this request may request the current values.- If there is no view with this name, then read access is not granted. π
WRITEVIEWβ the name of the MIB view (as set up bycreateViewor equivalent) defining the MIB objects for which this request may potentially SET new values.- If there is no view with this name, then read access is not granted. (yes, it says read access here, that's just what the page says, don't come for me π)
NOTIFYVIEWβ the name of the MIB view (as set up bycreateViewor equivalent) defining the MIB objects which may be included in notification request.- > Note that this aspect of access control is not currently supported. π
π deleteAccess GROUPNAME [CONTEXTPREFIX] MODEL LEVEL
Delete an entry from the SNMPv3 access table, which removes the specified access control settings. The entry to be removed is indexed by the group name, context prefix, security model and security level values, and those should match the ones used in the corresponding createAccess command (or equivalent). π«Ά
π createAuth GROUPNAME [CONTEXTPREFIX] MODEL LEVEL AUTHTYPE CONTEXTMATCH VIEW
Create an entry in the Net-SNMP extension to the standard access table, which allows a certain type of access to the MIB view for the principals in the specified group. The interpretation of GROUPNAME, CONTEXTPREFIX, MODEL, LEVEL and CONTEXTMATCH are the same as for the createAccess directive (copy-paste energy but make it correct β¨). The extension access table is indexed by the group name, context prefix, security model, security level and authtype values.
AUTHTYPEβ the style of access that this entry should be applied to. Seesnmpd.conf(5)andsnmptrapd.conf(5)for details of valid tokens. πVIEWβ the name of the MIB view (as set up bycreateViewor equivalent) defining the MIB objects for which this style of access is authorized.
π§ deleteAuth GROUPNAME [CONTEXTPREFIX] MODEL LEVEL AUTHTYPE
Delete an entry from the extension access table, which removes the specified access control settings. The entry to be removed is indexed by the group name, context prefix, security model, security level and authtype values, and those should match the ones used in the corresponding createAuth command (or equivalent). π
Note that snmpget REQUIRES an argument specifying the agent to query as described in the snmpcmd(1) manual page. yes it really says snmpget in a snmpvacm page. we don't question the lore π
π EXAMPLES π
Say you've got a pre-existing user dave (which could be set up using the snmpusm(1) command), and you wanna configure full read-write access to the whole OID tree. you'd run:
snmpvacm localhost createSec2Group 3 dave RWGroup
snmpvacm localhost createView all .1 80
snmpvacm localhost createAccess RWGroup 3 1 1 all all none
What did that just do? It creates a new security group named "RWGroup" containing the SNMPv3 user "dave", a new view "all" containing the full OID tree based on .iso(1), and then allows those users in the group "RWGroup" (i.e. "dave") both read- and write-access to the view "all" (i.e. the full OID tree) when using authenticated SNMPv3 requests. slay. π₯
Second example bestie, this time we set up read-only access to a portion of the OID tree:
snmpvacm localhost createSec2Group 3 wes ROGroup
snmpvacm localhost createView sysView system fe
snmpvacm localhost createAccess ROGroup 3 0 1 sysView none none
This creates a new security group named "ROGroup" containing the (pre-existing) user "wes", a new view "sysView" containing just the OID tree based on .iso(1).org(3).dod(6).inet(1).mgmt(2).mib-2(1).system(1), and then allows those users in the group "ROGroup" (i.e. "wes") read-access, but not write-access to the view "sysView" (i.e. the system group). look at us go π¦
π EXIT STATUS π
The following exit values are returned:
0β Successful completion β1β A usage syntax error (which displays a suitable usage message) or a request timeout. β°2β An error occurred while executing the command (which also displays a suitable error message). π
π LIMITATIONS π
okay bestie, real talk time, because I love you and I'm not gonna let you find this out the hard way π
This utility does not support configuring new community strings. So it's only useful for setting up new access control for SNMPv3 requests. You can use it to amend the access settings for community strings that already exist β but setting up brand new ones? Nope, not it, not happening, that's not this tool's moment π
And now, the part where the vibes get a lil crunchy π«
The use of numeric parameters for the secLevel and contextMatch parameters is less than intuitive. Like, it's giving "you will simply have to memorize this", no cap. These commands do not provide the full flexibility of the equivalent config file directives. So the config file girlies are lowkey eating while the command-line girlies are just standing there π§ββοΈ
Also, there is (currently) no equivalent to the one-shot configure directives rouser and rwuser. Just so you know. So you don't go looking for them and end up sad π
π So the tl;dr of the limitations: SNMPv3 access control = yes, new community strings = no, full config-file-level power = no,rouser/rwuserone-shot magic = not yet. Adjust your expectations accordingly, queen π
π SEE ALSO π
Go read these, they're the whole friend group fr fr:
snmpcmd(1)snmpusm(1)snmpd.conf(5)snmp.conf(5)- RFC 2575
- Net-SNMP project FAQ
and that's the whole page bestie!! this one's from V5.9.5.2, dated 05 Sep 2006, and it lives in the man pages as SNMPVACM(1) π¦
go forth and configure your access control, you absolute icon πβ¨π
π¦ where this page comes from
- alpine 3.23: net-snmp-doc 5.9.5.2-r0 Β· Net-SNMP
- alpine 3.24: net-snmp-doc 5.9.5.2-r0 Β· Net-SNMP
- arch rolling: net-snmp 5.9.5.2-2 Β· BSD
- fedora 44: net-snmp-utils 1:5.9.5.2-4.fc44 Β· MIT-CMU AND BSD-3-Clause AND MIT
- nixos 26.05: net-snmp 5.9.5.2
- nixpkgs unstable: net-snmp 5.9.5.2
- ubuntu stonking: snmp 5.9.5.2+dfsg-2.1ubuntu5
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms