Bug 1695363

Summary: MIB pass-through does NOT pass STRING VALUE for snmpset STRING oid type
Product: Red Hat Enterprise Linux 7 Reporter: Chris Cheney <ccheney>
Component: net-snmpAssignee: Josef Ridky <jridky>
Status: CLOSED ERRATA QA Contact: David Jež <djez>
Severity: high Docs Contact:
Priority: high    
Version: 7.6CC: dbodnarc, djez, fkrska, mike.hauth, ovasik, tcrider
Target Milestone: rcKeywords: EasyFix, Patch, Reproducer
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: net-snmp-5.7.2-44.el7 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-31 19:54:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1716965    

Description Chris Cheney 2019-04-02 22:50:34 UTC
Description of problem:

  snmpd does not pass through snmpset 'string' types to 'pass' scripts.

  This was fixed in upstream net-snmp 5.7.3 shortly after the version in RHEL7.

  https://sourceforge.net/p/net-snmp/mailman/message/34272858/


Version-Release number of selected component (if applicable):

  net-snmp 5.7.2


How reproducible:

  Every time.


Steps to Reproduce:

  I created a simple reproducer:

        Slightly modified stock /etc/snmp/snmpd.conf

          $ cat /etc/snmp/snmpd.conf | grep -v "^#\|^$"
          com2sec notConfigUser  default       public
          group   notConfigGroup v1           notConfigUser
          group   notConfigGroup v2c           notConfigUser
          view    systemview    included   .1.3.6.1.2.1.1
          view    systemview    included   .1.3.6.1.2.1.25.1.1
          view    systemview      included        .1                                            <- Modified
          access  notConfigGroup ""      any       noauth    exact  systemview systemview none  <- Modified
          syslocation Unknown (edit /etc/snmp/snmpd.conf)
          syscontact Root <root@localhost> (configure /etc/snmp/snmp.local.conf)
          dontLogTCPWrappersConnects yes
          pass 1.3.6.1.4.1.103.1.23.1 /root/passtest                                            <- Modified

        Simple test script that does nothing but write out the args:

          $ cat passtest
          #!/bin/bash
          date >> /tmp/passtest.log
          echo $\@ - $@ >> /tmp/passtest.log

        Running snmpget works (error is due to simple script):

          $ snmpget -v 1 -c public localhost .1.3.6.1.4.1.103.1.23.1
          Error in packet
          Reason: (noSuchName) There is no such variable name in this MIB.
          Failed object: SNMPv2-SMI::enterprises.103.1.23.1

          $ cat /tmp/passtest.log 
          Tue Apr  2 17:36:19 CDT 2019
          $@ - -g .1.3.6.1.4.1.103.1.23.1

        Running snmpset works for integer type:

          $ snmpset -v 1 -c public localhost .1.3.6.1.4.1.103.1.23.1 integer 613
          SNMPv2-SMI::enterprises.103.1.23.1 = INTEGER: 613

          $ cat /tmp/passtest.log 
          Tue Apr  2 17:34:54 CDT 2019
          $@ - -g .1.3.6.1.4.1.103.1.23.1
          Tue Apr  2 17:34:54 CDT 2019
          $@ - -s .1.3.6.1.4.1.103.1.23.1 integer 613

        Running snmpset does NOT work for string type:

          $ snmpset -v 1 -c public localhost .1.3.6.1.4.1.103.1.23.1 string "hello"
          SNMPv2-SMI::enterprises.103.1.23.1 = STRING: "hello"

          $ cat /tmp/passtest.log 
          Tue Apr  2 17:38:01 CDT 2019
          $@ - -g .1.3.6.1.4.1.103.1.23.1
          Tue Apr  2 17:38:01 CDT 2019
          $@ - -s .1.3.6.1.4.1.103.1.23.1 string


Actual results:

   snmpset is not passing the actual _string value_ when setting a 'string' oid


Expected results:

  snmpset should also pass the actual _string value_ when setting a 'string' oid

Comment 9 errata-xmlrpc 2020-03-31 19:54:44 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:1081