Re: VACM usage for multiple table restrictions

Hi -

> From: "JEWITT Jessie / FTR&D / US" <[email protected]>
> To: <[email protected]>
> Cc: "STEPHAN Emile FTRD/DAC/LAN" <[email protected]>; "OUENSANGA Olivier / FTR&D / US"
<[email protected]>
> Sent: Tuesday, June 24, 2003 6:42 PM
> Subject: VACM usage for multiple table restrictions
>

>
> Randy et al-
>      We are looking at using VACM for the IPPM MIB, and have a few questions
> that have come up in our testing of this functionality:
>
> 1) It appears that for the VIEW statements, you can essentially only
> associate 1 incl/excl per view, and only associate 1 access statement for a
> particular group to 1 view.

What do you mean by "VIEW statements"?
The diagram in section 3.1 of http://www.ietf.org/rfc/rfc3415.txt shows the
information needed to make the access decision.

> What if we need to have 1 access statement associated to multiple views?

What do you mean by "access statement"?

> For example, I want to give "mygroup"  access to row 1  in table  X of my
> mib, access to row 1 in another table Y of my mib,
> and then access to all other scalars and tables in the MIB. Can this be
> done?? How?

Easily.

In vacmViewTreeFamilyTable, create rows with vacmViewTreeFamilyViewName
equal to whatever name you want to give the view, and with vacmViewTreeFamilySubtree
equal to { X }, { Y }, { X 1 0 1 }, { Y 1 0 1} , and { MIB }.  For the first two rows, the
vacmViewTreeFamilyType would be "excluded(2)", and the others would be
"included(1)".  For the third and fourth ones,  the vacmViewTreeFamilyMask
would have a "0" in the position where I've used a "0" in the vacmViewTreeFamilySubtree
value, to indicate wildcarding so you get all the columns.

> 2) How does one specify an include statement on a view for a table that is
> indexed on another table index? It also appears that when tables are indexed
> on strings, that the string values need to be expressed in
> ascii  (at least in the snmpd.conf file for netSNMP).

Questions about the configuration files for specific packages probably belong
on another mailing list.

Randy