>> setaccess limitedgroup "" v2c noAuthNoPriv prefix log anything
Dave> What is this access view being applied to?
Wes> currently just the OID of the trap.
Good - that feels more sensible than the VACM approach of
shoehorning the notifyView to cover both trap OIDs *and*
the payload varbinds.
Wes> redesigning the VACM tokens will be quite
Wes> a bit of work both in design and in code (what you're
Wes> proposing requires state between token parsers
Does it *inherently* requires state between token parsers,
or is that just a consequence of the current implementation
approach?
Let me have a couple of days to look at this over the
weekend, and I should be able to suggest something a little
more definite by Monday.
>> ipv4logcommunity -v execute xyzzy
Dave> I don't understand this one.
Wes> Well, it's not that trivial it turns out....
Wes> The problem comes from the way
Wes> these wrappers always assume generation of a new
Wes> group as well as just the access line.
>> ipv4logcommunity mycommunity
>> ipv4executecommunity mycommunity
Wes> Will not work.
Much the same comment applies - are these limitations
inherent in the structure of the VACM directives, or
just a feature of the current implementation?
I certainly feel that having one filter specified via
the choice of directive, and additional ones added using
a different flag is unnecessarily confusing.
Wes> A better example would have been:
>> ipv4authcommunity -v log -v execute xyzzy
Yup - that's much better, though it does raise the
question of what the effect should be of
ipv4authcommunity xyzzy
Personally, I'd probably go for a mandatory positional
field - something like:
ipv4authcommunity log,execute xyzzy
Wes> I'm not sure I wanted the flag syntax (-v) or to use
Wes> something like log|execute or something...
That would work as well. Comma-separated (or possibly
colon-separated) feels more consistent with how we
represent lists in other places.
Wes> This is the one
Wes> thing I'm not happy with generally, but the options are
Wes> all bad in different ways.
So let's have a bit of discussion about what the options
are, and *why* they are bad. You never know, the combined
expretise of the whole Net-SNMP community might actually
be able to come up with something a little bit better
than you on your own :-)
Wes> There are ipv4 and ipv6 prefixes to indicate what the
Wes> community is to be used under for which transport
Actually, that's something else that has bitten me recently
(in conjunction with the Event-MIB/iquery handling). Why
do we need a different directive for each transport? It's
obviously important to be *able* to limit access based on
the transport layer used, but what is the benefit of *forcing*
the administrator to do this.
A more natural (and flexible) approach would be to use the
existing transport-prefix mechanism:
community read-only myNetwork udp:10.0.0.0/8
community read-write myLoopback callback:*
community execute myTraps ipv4:10/8,ipv6:10/8
community log myTraps
(with the last implicitly matching *any* transport)
Dave> I was slightly surprised you didn't have a
Dave> "pre-decision" filter as well:
Dave> "Non-authenticated traps won't be processed at all"
Wes> What's a non-authenticated trap?
SNMPv3/noAuth, or community-based traps.
That was just an example - the real question was whether it
was worth having a separate initial filter, to control whether
the trap was accepted at all (before applying individual
action-specific filters)
Wes> There is an explicit rule that if
Wes> you don't have any authorization for anything it gets dropped.
Yes - that's what I'd expected.
I'm actually not too bothered about this issue - it would be
easy enough to add some additional "accept traps" pre-filter
handling if we decided there was a need for it.
I'm more concerned with getting the basic framework of
the configuration directives right at this stage.
Dave
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
