HI,

Wes - unfortunately, there are some MIB definitions that follow
the design pattern of using the security name from the SET
operation to do security semantics. For example, the access
function for object usmUserOwnAuthKeyChange must have knowledge
of the security name in the SET operation.

There are several other examples in the "DISMAN space". The
ones there are VERY broken. 

But back to the fundamental question...
 Should the semantics associated with objects be allowed to
 use attributes of an SNMP request, and if so, how are these
 attributes passed to access functions?
 Attributes include:
   1) protocol type (v1, v2c, v3)
   2) security model (comm(v1,v2c), usm, etc)
   3) security level
   4) security name

Regards,
/david t. perkins
On Fri, 2 Sep 2005, Wes Hardaker wrote:

> >>>>> On Wed, 27 Jul 2005 10:06:08 +0530, <[EMAIL PROTECTED]> said:
> 
> [sorry for the late response]
> 
> kanda> I have to get the V3 username of the manager who is sending
> kanda> get/set request for pariticular OID in mib2c generated code for
> kanda> that OID.
> 
> You should never do that ;-)
> 
> Seriously.  You're making some assumptions that all that data will be
> available to you at all times, and though if your mib is in the main
> agent it might be it's version and security model dependent which
> makes your mib code version and security model dependent, as well as
> it won't work at all in a subagent or through a proxy where that
> information isn't passed to the agent at all.
> 
> IMHO, you should really be designing your system so it doesn't require
> that or use the standard VACM configuration to disallow access to
> objects that you don't want to allow access to.
> 
> -- 
> Wes Hardaker
> Sparta, Inc.
> 
> 
> -------------------------------------------------------
> 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
> 



-------------------------------------------------------
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