Re: Issues with Net-SNMP 5.7.1 USM user list

On 2 February 2012 10:54, Hemanth Abbina <[email protected]> wrote:
> 1. The library maintains a global USM users list. USM users are
> differentiated based on the security name and engine ID. But, say if I
> change the auth/priv password of the existing user, in the middle, it
> doesn't reflect in the list of users as it always retrieves the old user
> from the list only.


The user will be the same, yes - but the data structure for that user
should now have the new password.   Looking at the code for processing
usmUserAuthKeyChange SET requests  (in mibgroup/snmpv3/usmUser.c)
the routine write_usmUserAuthKeyChange() end up invoking the
following code fragment   (as part of the ACTION block):

     uptr = usm_parse_user(name, name_len);
         :
     memdup(&uptr->authKey, buf, buflen);    // buf contains the new
localised key
     uptr->authKeyLen = buflen;


How exactly are you changing the password(s) ?



> I think it should compare the auth/priv passwords also

The agent cannot actually compare the passwords, since the
new password isn't ever sent over the network.   The algorithm for
updating the password handling is covered in the DESCRIPTION clause
of the relevant MIB objects  (usmUser{,Own}{Auth,Priv}KeyChange
within SNMP-USER-BASED-SM-MIB)

> while selecting the users or it should edit the passwords appropriately.

"editing the passwords" is a bit of an over-simplification,
but that's essentially what it does.



> Could anyone please suggest us on what to do in this case ?

I'm not entirely clear as to exactly what the problem is here.

Can you give a bit more detail about exactly what you are trying,
what behaviour you see, and what you expected to happen?




> 2. One more observations is the list of users are maintained globally
> without any locks. This may pose issues while using this global list in
> multi-threaded applications.

Yes - this is semi-documented in the README.thread file:

    Unfortunately, the SNMPv3 support was added about the same
    time as the thread support and since they occurred in parallel the
    SNMPv3 support was never checked for multi-threading correctness.
    It is most likely that it is not thread-safe at this time.

We have long needed someone willing and able to take another look
at the thread-unsafe aspects of the library (and agent), and address
these deficiencies.   Volunteers always welcome!



Dave

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users