|
"Views" refers to subsets of the MIB tree which are configured to not let a specific user or group of users see or modify any objects which he/they should not have access to. Configuring views as used in the "vacmViewsTreeFamilyTable" and the "snmpNotifyFilterTable" involves including and excluding objects of the MIB tree.
As we work our way through this example you may notice that there are other, sometimes simpler, ways to represent the same thing.
As an example of a series of branches let’s use the following MIB tree in this example. We will allow our "userX" to have the following permissions:
green Read and Write
Red Neither Read nor Write
Yellow Read Only
The branches that are pointed out above will be used in the following example. It should be noted that the "objects" used in these definitions could equally well be leaf nodes.
First we define the "views" of the MIB and give them names for future reference. All of this is done in the VACM MIB views tab which represents the "vacmViewsTreeFamilyTable". The named view is the sum of all rows with the same "ViewName" where those branches of type "included" are added to the view while those of type "exclude" are subtracted from the view.
First we will define the "readView". Note that the OIDs below correspond to the branches indicated above. In this case the "interfaces" branch (1.3.6.1.2.1.2) is the branch which amoung those involved may not be read. (You might notice that at this point the "interfaces" branch has not been included anywhere and therefore the "excluded" statement is redundant and is included for clairity.)
The next step is to define the "write view" Of the four branches we are working with the "at" and "interfaces" branches are to be excluded as we demonstarate below:
You may have noticed that it is possible to get similar results by specifing inclusion of 1.3.6.1.2.1 and the exclusion of 1.3.6.1.2.1.3 for the readView. Using this definition is different than what we started out as but it gives the same rules for the four branches of interest but it does include all the branches 1.3.6.1.2.1.X where X >4. If this is not an issue then that method is acceptable. It does point out an interesting case where additional rules are required to remove ambiguity. Clearly the 1.3.6.1.2.1.3 OID is both on the included branch and the excluded branch. To handle this problem an additional rule was made up that the row with the largest number of matching sub-identifiers takes presidence. In this case the excluding row matches seven sub-identifiers while the including row matches only six sub-identifiers and therefore the excluding row takes presidence.
The "Mask" specified in each row is applied bitwise to the elements of the OID to specify if the resultant object must match the subtree spec. (indicated by a "1") or if a match is not required (indicated by a "0"). This allows even more complexities and opens the door to many unintended branches being included in the views. It’s use can generally be avoided.
Now that we have defined our user and can specify a view of the MIB which we would like to restrict him to, we can explore the topic of "Linking Views with Users"
Configuring Views