[AGENT++] Question on VacmSecurityToGroupTable::getGroupName()

Pham, My V. (Mission Systems) My.Pham at ngc.com
Sat Nov 17 03:10:39 CET 2007


We have the need here to make v1/v2 read/write community strings
configurable.  They may assume different values from each other, not
necessarily "public" and "public".  Parts of the code that handled this
are: 
...
	vacm->addNewGroup(SecurityModel_v1, v1_readCommunity, 
		              "v1readgroup", storageType_volatile);
	vacm->addNewGroup(SecurityModel_v1, v1_writeCommunity, 
		              "v1writegroup", storageType_volatile);	
...
	vacm->addNewAccessEntry("v1readgroup", "",	
		                            SecurityModel_v1,
SecurityLevel_noAuthNoPriv, 
			             match_exact, 
			             "v1ReadView", "", "",
storageType_nonVolatile);
	vacm->addNewAccessEntry("v1writegroup", "",
		                            SecurityModel_v1,
SecurityLevel_noAuthNoPriv, 
			             match_exact, 
			             "", "v1WriteView", "", 		
			             storageType_nonVolatile);

This works well for both Get and Set, but only if read and write
community strings are different from each other.  If they are the same,
let's say "public", then the vacm->addNewGroup() commands above will add
a first mapping of "public" to v1readgroup, and then a second mapping of
"public" to v1writegroup in the vacmSecurityToGroupTable.  When an SNMP
command Get or Set is processed, the method
VacmSecurityToGroupTable::getGroupName() is called and it seems to
always return the first mapping to v1readgroup only, so Get command will
be executed succesfully because v1readgroup allows read access, but Set
will fail because it also gets the first mapping and write access is not
granted in the  v1readgroup.  I can add "v1WriteView" to the v1readgroup
and it works but that defeats the purpose of separating read and write
community.

Any suggestion?

Thanks!!



More information about the AGENTPP mailing list