Nov 14 04:12:05 hawk kernel: audit(1163502725.021:172): avc: denied { read write } for pid=29815 comm="umount" name="[2054955]" dev=sockfs ino=2054955 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:automount_t:s0 tclass=udp_socket Nov 14 04:13:11 hawk kernel: audit(1163502791.161:173): avc: denied { read write } for pid=29942 comm="mount" name="[2056142]" dev=sockfs ino=2056142 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:automount_t:s0 tclass=tcp_socket Nov 14 18:52:32 hawk kernel: audit(1163555552.634:185): avc: denied { read write } for pid=11395 comm="mount" name="[2174114]" dev=sockfs ino=2174114 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:automount_t:s0 tclass=udp_socket Nov 15 04:28:47 hawk kernel: audit(1163590127.023:187): avc: denied { read write } for pid=20002 comm="umount" name="[2315680]" dev=sockfs ino=2315680 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:automount_t:s0 tclass=tcp_socket Nov 15 04:29:10 hawk kernel: audit(1163590150.901:188): avc: denied { read write } for pid=20012 comm="mount" name="[2315749]" dev=sockfs ino=2315749 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:automount_t:s0 tclass=tcp_socket Nov 15 04:30:17 hawk kernel: audit(1163590217.009:189): avc: denied { read write } for pid=20143 comm="mount" name="[2316981]" dev=sockfs ino=2316981 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:automount_t:s0 tclass=udp_socket Nov 15 04:31:22 hawk kernel: audit(1163590282.009:190): avc: denied { read write } for pid=20329 comm="umount" name="[2318432]" dev=sockfs ino=2318432 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:automount_t:s0 tclass=tcp_socket Nov 15 04:31:29 hawk kernel: audit(1163590289.011:191): avc: denied { read write } for pid=20540 comm="umount" name="[2319903]" dev=sockfs ino=2319903 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:automount_t:s0 tclass=udp_socket Version-Release number of selected component (if applicable): selinux-policy-2.4.3-2.fc6 Does not appear to causing any problems that I can see though.
This looks like a leaked file descriptor. I don;t believe mount command is going to access udp_sockets created by the automounter.
what version of autofs?
I think this is fixed with autofs-5.0.1-0.rc2.22. It has been installed, but automount had not been restarted. Rebooting seems to have cleared it up.
Spoke too soon, they're back: Nov 30 06:18:57 hawk kernel: audit(1164892737.013:52): avc: denied { read write } for pid=3804 comm="umount" name="[475583]" dev=sockfs ino=475583 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:automount_t:s0 tclass=tcp_socket Nov 30 06:18:57 hawk kernel: audit(1164892737.013:53): avc: denied { read write } for pid=3804 comm="umount" name="[475584]" dev=sockfs ino=475584 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:automount_t:s0 tclass=tcp_socket
(In reply to comment #4) > Spoke too soon, they're back: > > Nov 30 06:18:57 hawk kernel: audit(1164892737.013:52): avc: denied { read > write } for pid=3804 comm="umount" name="[475583]" dev=sockfs ino=475583 > scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:automount_t:s0 > tclass=tcp_socket > Nov 30 06:18:57 hawk kernel: audit(1164892737.013:53): avc: denied { read > write } for pid=3804 comm="umount" name="[475584]" dev=sockfs ino=475584 > scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:automount_t:s0 > tclass=tcp_socket > Dan you mentioned that this could be a descriptor leak. Tell me more about the meaning of this message. Is it just saying that mount is trying to use a socket that is in fact still open by automount? I find this a bit strange as mount is a client and so the RPC layer in glibc will hunt for a free socket in the same way for both automount and mount. It's also possible that another mount thread will have a socket(s) open if more than one mount request is happening at the same time. Anyway, I'll look to see if I can find a leak. Ian
When you fork/exec a process. By default all open file descriptors get handed to the new process. When the kernel starts the process, it runs through the open file descriptor and checks whether or not the new process has the same access to these open descriptors as the parent. So if the parent opened a file descriptor Read/Write the child will check if it has read/write on the descriptr. When it does this check, SELinux interferes and says no, you are not allowed to use this file descriptor and closes childs connection. Then it generates the AVC. Most of the time, the child process does not need access to these file descriptors. So the apps all work the way they are designed. But we get these ugly descriptors. In some cases this could be a potential security problem. When we first started with SELinux we got a lot of programs wanting access to /dev/initctrl. Turns out the init process was opeing a file descriptor to this file and then allowing all its children to inherit it. This would then allow any subprocess to change the run level of the machine. fcntl has an interface that allows you to close all descriptors on exec fctnl(fd, F_SETFD, FD_CLOEXEC)
(In reply to comment #6) > > fcntl has an interface that allows you to close all descriptors on exec > > fctnl(fd, F_SETFD, FD_CLOEXEC) Yes. I've set that for all the files I could. But I don't think I set it for sockets. Since it's likely that there will be sockets open at fork I'll go through and make sure I set it for them also. Ian
(In reply to comment #7) > (In reply to comment #6) > > > > fcntl has an interface that allows you to close all descriptors on exec > > > > fctnl(fd, F_SETFD, FD_CLOEXEC) > > Yes. I've set that for all the files I could. > But I don't think I set it for sockets. > > Since it's likely that there will be sockets open > at fork I'll go through and make sure I set it for > them also. > > Ian > I've added the close-on-exec to the socket creation in autofs-5.0.1-0.rc2.36. Orion could you check this when the update reaches the mirrors please. Ian
This does appear to fix the issue. Thanks!
This might still be there with autofs-5.0.1-0.rc2.43.0.2 and selinux-policy-2.4.6-30.el5 on RHEL5. See bug 233481 for detail.