On Fri, 2005-09-02 at 22:59 -0700, Wes Hardaker wrote:

> /me puts his fingers where his mouth is.


> In short summary, I'm overriding the access methods within the VACM
> stuff so that read becomes "ability to log", and write becomes
> "ability to execute" and notify becomes "ability to forward".

fingers and mouth is right.   <Baaaarff!!>
Sorry, Wes - but that sucks *big* time.

The underlying idea of restricting access to different categories
of action (separately configurable) is probably sensible enough.
But trying to shoehorn this into the existing VACM table is Just
Plain Wrong.

If we're going to do this, then let's Do It Right.
I suggest we need to define a new MIB to configure and control this
trap handling access.  And that should be flexible enough to cope
with multiple types of handling activity - hardwiring just three
possible categories seems decidedly shortsighted, IMO.



I'm sure that I remembered seeing something in the SNMPv3 specs about
how to apply VACM settings to notifications.  But re-reading the RFCs,
it seems to only (strictly) apply when *sending* notifications.  The
'notify-view' is meant to be applied to both the OIDs of individual
varbinds in the payload list (see RFC 3415, section 2.5) and to the
snmpTrapOID.0 value (see RFC 3413, section 3.3, para (3)).
  [*why* they decided to combine two very different concepts into
   a single view is beyond me!  Except that having seen something
   of how these bodies work in practise - it's not :-( ]


There's probably a case to be made for applying either or both of
these checks to incoming notifications as well.  It may be outside
the strict letter of the specifications, but it's certainly within
the spirit of them.   Personally, I'd be inclined to just check
the snmpTrapOID.0 value - acting as a first-level filter, before
applying more specific tests for particular styles of processing.

And it probably makes sense to re-use much of the existing VACM
code to implement such tests.   But we should probably be looking
at *augmenting* the vacmAccessTable, rather than forcing things
into that straightjacket.



Dave


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to