During the upgrade of 389-ds-base 1.2.6 to 1.2.6.1, I received the following SELinux AVCs related to net-snmp: node=ds.messinet.com type=AVC msg=audit(1285995330.668:21708): avc: denied { write } for pid=1304 comm="ldap-agent-bin" name="net-snmp" dev=md0 ino=1253403 scontext=system_u:system_r:dirsrv_snmp_t:s0 tcontext=system_u:object_r:snmpd_var_lib_t:s0 tclass=dir node=ds.messinet.com type=AVC msg=audit(1285995330.668:21708): avc: denied { remove_name } for pid=1304 comm="ldap-agent-bin" name="ldap-agent.conf" dev=md0 ino=1179923 scontext=system_u:system_r:dirsrv_snmp_t:s0 tcontext=system_u:object_r:snmpd_var_lib_t:s0 tclass=dir node=ds.messinet.com type=AVC msg=audit(1285995330.668:21708): avc: denied { rename } for pid=1304 comm="ldap-agent-bin" name="ldap-agent.conf" dev=md0 ino=1179923 scontext=system_u:system_r:dirsrv_snmp_t:s0 tcontext=system_u:object_r:snmpd_var_lib_t:s0 tclass=file node=ds.messinet.com type=AVC msg=audit(1285995330.668:21708): avc: denied { add_name } for pid=1304 comm="ldap-agent-bin" name="ldap-agent.0.conf" scontext=system_u:system_r:dirsrv_snmp_t:s0 tcontext=system_u:object_r:snmpd_var_lib_t:s0 tclass=dir node=ds.messinet.com type=SYSCALL msg=audit(1285995330.668:21708): arch=c000003e syscall=82 success=yes exit=0 a0=7fffc6ae1340 a1=7fffc6ae0940 a2=ffffffffffffffa8 a3=7fffc6ae0620 items=0 ppid=1 pid=1304 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ldap-agent-bin" exe=2F7573722F7362696E2F6C6461702D6167656E742D62696E202864656C6574656429 subj=system_u:system_r:dirsrv_snmp_t:s0 key=(null) node=ds.messinet.com type=AVC msg=audit(1285995330.668:21709): avc: denied { create } for pid=1304 comm="ldap-agent-bin" name="ldap-agent.conf" scontext=system_u:system_r:dirsrv_snmp_t:s0 tcontext=system_u:object_r:snmpd_var_lib_t:s0 tclass=file node=ds.messinet.com type=SYSCALL msg=audit(1285995330.668:21709): arch=c000003e syscall=2 success=yes exit=9 a0=7fffc6ae0660 a1=441 a2=1b6 a3=0 items=0 ppid=1 pid=1304 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ldap-agent-bin" exe=2F7573722F7362696E2F6C6461702D6167656E742D62696E202864656C6574656429 subj=system_u:system_r:dirsrv_snmp_t:s0 key=(null) node=ds.messinet.com type=AVC msg=audit(1285995330.668:21710): avc: denied { unlink } for pid=1304 comm="ldap-agent-bin" name="ldap-agent.0.conf" dev=md0 ino=1179923 scontext=system_u:system_r:dirsrv_snmp_t:s0 tcontext=system_u:object_r:snmpd_var_lib_t:s0 tclass=file node=ds.messinet.com type=SYSCALL msg=audit(1285995330.668:21710): arch=c000003e syscall=87 success=yes exit=0 a0=7fffc6ae1350 a1=7fffc6ae12c0 a2=7fffc6ae12c0 a3=7fffc6ae1030 items=0 ppid=1 pid=1304 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ldap-agent-bin" exe=2F7573722F7362696E2F6C6461702D6167656E742D62696E202864656C6574656429 subj=system_u:system_r:dirsrv_snmp_t:s0 key=(null)
Did these AVCs happen during the actual upgrade, or are you still seeing them now that the upgrade is complete? Does ldap-agent start and stop successfully?
I am seeing a similar AVC when starting or stopping dirsrv-snmp with a fresh install of 389-ds-base-1.2.6-1.2 on a F14 beta system: type=AVC msg=audit(1286239191.803:21148): avc: denied { write } for pid=5942 comm="ldap-agent-bin" name="lib" dev=dm-0 ino=13 scontext=unconfined_u:system_r:dirsrv_snmp_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir type=SYSCALL msg=audit(1286239191.803:21148): arch=c000003e syscall=83 success=no exit=-13 a0=7fff8e626f10 a1=1c0 a2=ffffffffffffff80 a3=7fff8e626be0 items=0 ppid=5941 pid=5942 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="ldap-agent-bin" exe="/usr/sbin/ldap-agent-bin" subj=unconfined_u:system_r:dirsrv_snmp_t:s0 key=(null) I believe that something in the net-snmp libraries is causing the subagent to attempt to write something in the /var/lib area. Since my system is freshly installed and I haven't used net-snmp on it yet, my directory structure is likely different than yours in /var/lib. I believe that this is why our AVCs are different. Do you have a /var/lib/net-snmp directory (or some other directory at that level related to SNMP)? What is the SELinux context on that directory (check with ls -lZ)? It appears that the libraries are causing the subagent to attempt to write some sort of config file cache in that area.
Once I started snmpd on my system for the first time, it created /var/lib/net-snmp with a context of snmpd_var_lib_t. If I then restart dirsrv-snmp, I see similar AVCs to what you are seeing. I believe that these AVCs are harmless and dirsrv-snmp should be working fine, but we still should adjust the policy to allow dirsrv_snmp_t to manage snmp_var_lib_t files. I am a bit unsure about allowing dirsrv_snmp_t to create the /var/lib/net-snmp directory itself as I don't know if it will have the proper context for snmpd to use it.
(In reply to comment #1) > Did these AVCs happen during the actual upgrade, or are you still seeing them > now that the upgrade is complete? Does ldap-agent start and stop successfully? I saw them during the upgrade (in permissive mode). Switching to enforcing mode, dirsrv-snmp seems to restart without AVCs.
These SNMP related AVCs are being dealt with in bug 671584. Marking this as a duplicate. *** This bug has been marked as a duplicate of bug 671584 ***