>>>>> On Thu, 20 Oct 2005 16:54:21 +0100, Dave Shield <[EMAIL PROTECTED]> said:
Dave> So I presume we're looking at 5.3.pre1 being next Friday,
Dave> rather than tomorrow then? Which suits me fine - I just
Dave> wasn't sure what had been decided.
I think I can have it done by tomorrow.
>> What's out there
>> now is simply bad. But I should also have the time to get it done by
>> 5.3, assuming I can reuse the infrastructure that we have today which
>> I think fits anyway.
Dave> I've now managed to track down the previous discussion, and refreshed
Dave> my memory of what was proposed. It looks as if we'd reached a
Dave> rough consensus over augmenting the VACM access table (or something
Dave> conceptually similar) with additional entries to cover trap behaviour.
Dave> Does that match what you've been working towards?
Index: include/net-snmp/library/vacm.h
===================================================================
RCS file: /cvsroot/net-snmp/net-snmp/include/net-snmp/library/vacm.h,v
retrieving revision 5.4
diff -u -p -r5.4 vacm.h
--- include/net-snmp/library/vacm.h 30 Aug 2005 00:36:16 -0000 5.4
+++ include/net-snmp/library/vacm.h 20 Oct 2005 16:13:27 -0000
@@ -61,15 +61,29 @@ extern "C" {
#define CONTEXT_MATCH_EXACT 1
#define CONTEXT_MATCH_PREFIX 2
+
+/* SNMPD usage: get/set/send-notification views */
+#define VACM_VIEW_READ 0
+#define VACM_VIEW_WRITE 1
+#define VACM_VIEW_NOTIFY 2
+
+/* SNMPTRAPD usage: log execute and net-access (forward) usage */
+#define VACM_VIEW_LOG 3
+#define VACM_VIEW_EXECUTE 4
+#define VACM_VIEW_NET 5
+
+/* Maximum number of views in the view array */
+#define VACM_MAX_VIEWS 8
+
+ void init_vacm(void);
+
struct vacm_accessEntry {
char groupName[VACMSTRINGLEN];
char contextPrefix[VACMSTRINGLEN];
int securityModel;
int securityLevel;
int contextMatch;
- char readView[VACMSTRINGLEN];
- char writeView[VACMSTRINGLEN];
- char notifyView[VACMSTRINGLEN];
+ char views[VACM_MAX_VIEWS][VACMSTRINGLEN];
int storageType;
int status;
Dave> a) the code used to implement this filtering
Dave> b) the configure directives used to control it (locally)
Dave> c) the MIB interface used to control it (remotely)
Dave> I presume that when you talk about "reusing the infrastructure
Dave> we have", you're mostly referring to the existing vacm-related
Dave> code. Yes?
Yes.
Dave> I'm probably more concerned about the other two (and particularly
Dave> the MIB interface). That's probably where backwards compatibility
Dave> is most likely to restrict us in the future.
I don't plan on hitting (c) by tomorrow. I think remote access can be
done later. Sure, it'd be nice to have deployed at the same time but
there is no technical reason why it can't come later and thus delaying
the other benefits doesn't seem worth it.
Dave> What do you propose as regards b) and c) above?
b) I'll post a better list of tokens a bit later. But functionally:
A new token for setting access for a single acm entry:
Previously we had this:
access name context model level prefx read write notify
I'd be adding this:
setaccess name context model level prefx viewname viewval
where view name would be one of read, write, notify, log, execute, net
And there would be wrapper tokens equivalent to the rocommunity like
tokens to quick-create access for a given community for a given type
(eg "logcommunity").
Dave> The other relevant question is how much granularity are
Dave> you planning for the initial 5.3 release? A simple
Dave> "filter incoming traps" (and leave the finer-grained
Dave> handling for later), or more control right from the
Dave> start? If so, what?
Filtering on the actions called for an incoming trap. IE, the
community of "public" may only be granted the right to log it but not
execute. The snmpv3 user "wes" might be allowed to do all actions.
--
Wes Hardaker
Sparta, Inc.
-------------------------------------------------------
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
