> From: dave.shi...@googlemail.com 
> [mailto:dave.shi...@googlemail.com] On Behalf Of Dave Shield
> Sent: Tuesday, December 08, 2009 10:14 AM
> To: Lewis Adam-VNQM87
> Cc: net-snmp-users@lists.sourceforge.net
> Subject: Re: vacm_getAccessEntry() doesn't look for best match
> 
> 2009/12/7 Lewis Adam-VNQM87 <vnq...@motorola.com>:
> > Looking at version 5.5 of the net-snmp suite ... in snmplib\vacm.c, 
> > the function
> > vacm_getAccessEntry() just gets the first entry that matches the 
> > search criteria rather than search for the one with the 
> highest securityLevel.
> 
> > Am I missing something or is this just a to-be-done?
> 
> No - I think you've spotted a bug.
> 
> Note that it's not just a matter of choosing the "highest 
> securityLevel" - there's a whole set of priority decisions 
> defined in RFC 3415 that the code is not currently applying.
> 
> Please try the attached patch, and see whether this leads to 
> the expected behaviour
> 
Hi Dave,
  many thanks for responding so quickly - apologies for not doing
likewise. I have tested the patch and it works fine. Of course you are
right that it is not just about security levels although in our
configuration, we are less concerned about context prefixes.

One thing I was curious about is that if the example (recommended?)
default configuration given in the RFCs specifies an "initial" user with
what is effectively a read-write "internet" view and a read-only
"restricted" view, why hasn't this problem been spotted before? As far
as I can tell, if someone tried to use this configuration, they would
find they could not do any SNMP SETs.

Regards,
Adam.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Reply via email to