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
