Description of problem: When running an snmpd daemon on a RedHat machine with IPv6 disabled, the daemon hangs when it is queried for attributes related to IPv6. In particular, doing a full snmpwalk will display the behaviour. Version-Release number of selected component (if applicable): net-snmp-5.3.1-24.el5_2.1 How reproducible: Every time. Steps to Reproduce: 1. Disable IPv6 on a machine, by adding these two lines to /etc/modprobe.conf: alias net-pf-10 off alias ipv6 off 2. Reboot the machine 3. Create a very basic /etc/snmp/snmpd.conf: rocommunity read public default 4. Start snmpd daemon: service snmpd start 5. Query it with snmpwalk: snmpwalk -v 2c -c public localhost .1 Actual results: It will hang after TCP-MIB::tcpConnRemPort (or around that). Even after breaking the snmpwalk with Ctrl+C, the snmpd daemon will be unresponsive and won't answer any more queries. On /var/log/messages you will see messages such as: snmpd[32695]: could not open /proc/net/if_inet6 snmpd[32695]: cannot open /proc/net/snmp6 snmpd[32695]: could not open /proc/net/tcp6 You have to restart the daemon to be able to do SNMP queries again. Expected results: The daemon should probably detect that IPv6 is not enabled/not available and should just skip those sessions of the MIB. Even if it logs an error, it should certainly not hang and stop answering queries.
I can't reproduce the bug. I fixed something similar for RHEL 5.2, see bug #444236. The snmpd indeed prints "could not open /proc/net/if_inet6", but should recover from such errors and anything above net-snmp-5.3.1-23 should work without IPv6 module. Please double check that you use latest version and if it's still reproduceable, then please provide strace of snmpd.
Yes, actually it seems that the upgrade to 5.3.1-24.el5_2.1 fixed this problem. I was confused, though, because I was seeing the same symptom (snmpwalk hanging) and same log messages. I went further and I saw that now what happens is that, just after restarting snmpd, the first time I run snmpwalk, it hangs just after TCP-MIB::tcpOutRsts.0 for some seconds and actually makes snmpwalk time out. On the next tries, that no longer happens. I saw that when it happens several lines like the ones below are written to /var/log/audit/audit.log: type=AVC msg=audit(1215196841.911:1218551): avc: denied { sys_ptrace } for pid=29322 comm="snmpd" capability=19 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:system_r:snmpd_t:s0 tclass=capability type=SYSCALL msg=audit(1215196841.911:1218551): arch=c000003e syscall=89 success=no exit=-13 a0=7fff621bcff0 a1=7fff621be000 a2=ff a3=3 items=0 ppid=1 pid=29322 auid=1114 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="snmpd" exe="/usr/sbin/snmpd" subj=user_u:system_r:snmpd_t:s0 key=(null) I have a 26MB strace of snmpd, please let me know if you would like me to attach it to the bug. Thanks, Filipe
The machine where I tested it was not 100% updated to 5.2, it was a 5.1 installation and I had just upgraded net-snmp to the latest version to see if the problem still happened. I just tried it on a fully updated 5.2 machine, I rebooted it before starting the tests. I no longer have a timeout, but I continue to have some AVC messages: type=AVC msg=audit(1215197783.247:10562): avc: denied { ptrace } for pid=3060 comm="snmpd" scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=process type=SYSCALL msg=audit(1215197783.247:10562): arch=c000003e syscall=89 success=no exit=-13 a0=7fffb9d41330 a1=7fffb9d42340 a2=ff a3=3 items=0 ppid=1 pid=3060 auid=1114 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="snmpd" exe="/usr/sbin/snmpd" subj=user_u:system_r:snmpd_t:s0 key=(null) type=AVC msg=audit(1215197783.247:10563): avc: denied { ptrace } for pid=3060 comm="snmpd" scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=process type=SYSCALL msg=audit(1215197783.247:10563): arch=c000003e syscall=89 success=no exit=-13 a0=7fffb9d41330 a1=7fffb9d42340 a2=ff a3=3 items=0 ppid=1 pid=3060 auid=1114 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="snmpd" exe="/usr/sbin/snmpd" subj=user_u:system_r:snmpd_t:s0 key=(null) Should I be worried about this? Anyway, why would snmpd try to ptrace something? Thanks, Filipe
Strange, snmpd should not use ptrace, at least not directly. Anyway, I am able to reproduce it locally and I'll look at it.
net-snmp-5.3.1-24 (i.e. from RHEL 5.1) works without SELinux denials -> setting regression keyword
(In reply to comment #5) > net-snmp-5.3.1-24 (i.e. from RHEL 5.1) works without SELinux denials heh, net-snmp-5.3.1-19 is the working one (RHEL 5.1), -24 comes with RHEL 5.2 and produces the reported SELinux denials.
But with net-snmp-5.3.1-24, AFAIR, I had issues on machines with IPv6 disabled. Anyway, the "ptrace" problem seems to be less serious, since it happens only when snmpd starts and it doesn't leave the process hung, so I prefer to live with that one.
Use of course the version which is best working for you - the AVC is harmless. Still, it should be fixed... It's generated when snmpd retrieves value of TCP-MIB::tcpListenerProcess and TCP-MIB::tcpConnectionProcess, which were added in RHEL 5.2.
Reassigning to SELinux... SELinux reports AVC when snmpd reads /proc/<pid>/fd/*, see comment #3
Fixed in selinux-policy-2.4.6-141.el5
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
This bugzilla has Keywords: Regression. Since no regressions are allowed between releases, it is also being proposed as a blocker for this release. Please resolve ASAP.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0163.html