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