This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 215757 - avc: denied { read write } mount umount dev=sockfs scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:automount_t:s0 tclass=udp_socket/tcp_socket
avc: denied { read write } mount umount dev=sockfs scontext=system_u:system...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ian Kent
Brock Organ
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-15 11:54 EST by Orion Poplawski
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 5.0.1-0.rc2.36
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-18 00:23:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Orion Poplawski 2006-11-15 11:54:30 EST
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.
Comment 1 Daniel Walsh 2006-11-28 16:07:35 EST
This looks like a leaked file descriptor.  I don;t believe mount command is
going to access udp_sockets created by the automounter.
Comment 2 Jeffrey Moyer 2006-11-28 16:29:55 EST
what version of autofs?
Comment 3 Orion Poplawski 2006-11-29 17:47:04 EST
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.
Comment 4 Orion Poplawski 2006-11-30 11:27:42 EST
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
Comment 5 Ian Kent 2006-11-30 22:37:54 EST
(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


Comment 6 Daniel Walsh 2006-12-01 11:41:10 EST
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)
Comment 7 Ian Kent 2006-12-01 12:34:56 EST
(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
Comment 8 Ian Kent 2006-12-14 00:30:00 EST
(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
Comment 9 Orion Poplawski 2006-12-18 00:23:53 EST
This does appear to fix the issue.  Thanks!
Comment 10 Aleksey Nogin 2007-03-22 14:23:57 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.