Bug 215757

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.