Bug 207678 - Looks like autofs might be leaking an open file descriptor
Looks like autofs might be leaking an open file descriptor
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ian Kent
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-22 10:28 EDT by Daniel Walsh
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-19 14:07:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Add a socket close in an error path. (388 bytes, patch)
2006-09-22 14:02 EDT, Jeff Moyer
no flags Details | Diff

  None (edit)
Description Daniel Walsh 2006-09-22 10:28:19 EDT
Description of problem:

----
time->Thu Sep 21 18:10:33 2006
type=AVC_PATH msg=audit(1158876633.012:72):  path="socket:[219072]"
type=SYSCALL msg=audit(1158876633.012:72): arch=40000003 syscall=11 success=yes exit
=0 a0=b7b456dd a1=b7b456a0 a2=8280170 a3=0 items=0 ppid=6785 pid=7077 auid=500 uid=0
 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mount" exe="/bin
/mount" subj=user_u:system_r:mount_t:s0 key=(null)
type=AVC msg=audit(1158876633.012:72): avc:  denied  { read write } for  pid=7077 co
mm="mount" name="[219072]" dev=sockfs ino=219072 scontext=user_u:system_r:mount_t:s0
 tcontext=user_u:system_r:automount_t:s0 tclass=udp_socket


Indicates mount command is checking its access to a udp_socket owned by automount.
Comment 1 Jeff Moyer 2006-09-22 13:59:23 EDT
Can you provide some more information?  Please upload the contents of your maps.
 What were you doing at the time?  Do you use /net at all?
Comment 2 Jeff Moyer 2006-09-22 14:02:34 EDT
Created attachment 136955 [details]
Add a socket close in an error path.

I'm not convinced this patch will address the problem reported here, but this
is a valid bug fix.
Comment 3 Daniel Walsh 2006-09-22 15:19:16 EDT
Can't you just 
fcntl(socket, F_SETFL, FD_CLOEXEC);

The socket
Comment 4 Jeff Moyer 2006-09-22 15:57:00 EDT
Autofs opens and closes sockets when probing nfs servers.  I audited the code,
and I found one place where a socket wasn't closed.  Aside from that, we rely on
the RPC layer to close the socket upon a clnt_destroy.  In no case that I saw
did we fork and exec a process with open sockets.

To directly answer your question, yes, we could set the close on exec bit for
all file descriptors.  I'm not convinced this is the best way forward.  If there
is a file descriptor leak, then I want to know about it.

So, please answer my questions from comment #1.
Comment 5 Daniel Walsh 2006-09-22 16:30:13 EDT
This came from Pete Graner's machine.  I am not sure if this caused the avc or
not, but we were traversing /net/curly ...

Pete can you attach your maps?
Comment 6 Jeff Moyer 2006-09-22 17:29:53 EDT
If he is simply browsing /net/, then that isolates the problem enough, I think.
 What happens as a result?  Does this actually keep autofs from functioning?

I cannot reproduce this locally on my RHEL 5 system.  I have:

autofs-5.0.1-0.rc2.4
kernel 2.6.17-1.2677.el5

What versions of the kernel and autofs packages were in use when this bug was
produced?
Comment 7 Ian Kent 2006-09-22 22:54:09 EDT
(In reply to comment #3)
> Can't you just 
> fcntl(socket, F_SETFL, FD_CLOEXEC);
> 
> The socket

Nop. But sometimes we do.

The RPC code in autofs v5, while still not exactly right, tries to
reuse open sockets to reduce port usage so it's possible that a
socket is open when a mount command is spawned. That file handle
should be closed at exit of mount(8). Is this a problem?

If there are cases where a socket is never closed then we need to
fix that. I'll check the code also, as Jeff has done.

Ian
Comment 8 Daniel Walsh 2006-09-23 06:55:41 EDT
No as long as the execed app does not use the leaked descriptor, everything
works ok.  Basically when you fork a process, and exec the kernel usually hands
the execed program all open file descriors.  With SELinux, the context of the
newly execed app is checked for all access on every open file descriptor.  If
they execed app does not have the granted access, the kernel closes the socket
and reopens it connected to /dev/null.  And an AVC message is generated.  

So the problem here is the AVC message.  If the mount command has know need to
use the udp socket, this socket should be closed on exec.  This does not mean
that autofs can not continue to use the socket, but mount will not see it.
Comment 9 Ian Kent 2006-09-25 02:33:28 EDT
(In reply to comment #2)
> Created an attachment (id=136955) [edit]
> Add a socket close in an error path.
> 
> I'm not convinced this patch will address the problem reported here, but this
> is a valid bug fix.

Thanks Jeff, that's clearly a file handle leak.
I'm also not sure it was causing this issue.
Comment 10 Jeff Moyer 2006-10-12 12:52:05 EDT
Well, it looks like we'll not get any further information on this from the reporter.

Ian, if you actually do fork() and exec() with open file descriptors, then we
need to set the close on exec bit.  I was under the impression that we never did
that, and so this bug indicated a file descriptor leak.  Perhaps I misread the code.

So, can you make the necessary changes?
Comment 11 Ian Kent 2006-10-12 13:06:57 EDT
(In reply to comment #10)
> Well, it looks like we'll not get any further information on this from the
reporter.
> 
> Ian, if you actually do fork() and exec() with open file descriptors, then we
> need to set the close on exec bit.  I was under the impression that we never did
> that, and so this bug indicated a file descriptor leak.  Perhaps I misread the
code.
> 
> So, can you make the necessary changes?

There were some file descriptor leaks.
I'll be updating the rpm tomorrow.

I'm not sure that we caould be sure to get all file descriptors
with the close on exit but I'll have a look and set it on as
many as I can.

Ian


Comment 12 Ian Kent 2006-10-16 00:39:53 EDT
(In reply to comment #11)
> (In reply to comment #10)
> > Well, it looks like we'll not get any further information on this from the
> reporter.
> > 
> > Ian, if you actually do fork() and exec() with open file descriptors, then we
> > need to set the close on exec bit.  I was under the impression that we never did
> > that, and so this bug indicated a file descriptor leak.  Perhaps I misread the
> code.
> > 
> > So, can you make the necessary changes?
> 
> There were some file descriptor leaks.
> I'll be updating the rpm tomorrow.
> 
> I'm not sure that we caould be sure to get all file descriptors
> with the close on exit but I'll have a look and set it on as
> many as I can.

OK. I've commited a patch that should set close-on-exec for
most of the fds we use. Along with fixing the fd leaks I found
we should be OK now.

Ian

Comment 13 Ian Kent 2006-12-19 03:14:36 EST
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > Well, it looks like we'll not get any further information on this from the
> > reporter.
> > > 
> > > Ian, if you actually do fork() and exec() with open file descriptors, then we
> > > need to set the close on exec bit.  I was under the impression that we
never did
> > > that, and so this bug indicated a file descriptor leak.  Perhaps I misread the
> > code.
> > > 
> > > So, can you make the necessary changes?
> > 
> > There were some file descriptor leaks.
> > I'll be updating the rpm tomorrow.
> > 
> > I'm not sure that we caould be sure to get all file descriptors
> > with the close on exit but I'll have a look and set it on as
> > many as I can.
> 
> OK. I've commited a patch that should set close-on-exec for
> most of the fds we use. Along with fixing the fd leaks I found
> we should be OK now.

Do we know if this is fixed?

Ian

Comment 14 Aleksey Nogin 2007-03-22 14:17:09 EDT
I am getting something that might be related from RHEL 5: 

% dmesg
...
Mar 21 17:41:31 XXX setroubleshoot:      SELinux is preventing /bin/umount
(mount_t) "read write" to socket:[964509] (automount_t).      For complete
SELinux messages. run sealert -l 619111cc-de7d-4e74-aaf4-6ff9fc0a4c11
Mar 22 09:59:05 XXX setroubleshoot:      SELinux is preventing /bin/mount
(mount_t) "read write" to socket:[1440127] (automount_t).      For complete
SELinux messages. run sealert -l 803e8a01-6ba1-4e70-b9b4-d236309513a7
Mar 22 09:59:05 XXX setroubleshoot:      SELinux is preventing /bin/mount
(mount_t) "read write" to socket:[1440527] (automount_t).      For complete
SELinux messages. run sealert -l c7b25a24-dbda-4c93-9ef0-9de2667b3e71
Mar 22 09:59:32 XXX setroubleshoot:      SELinux is preventing /bin/mount
(mount_t) "read write" to socket:[1503463] (automount_t).      For complete
SELinux messages. run sealert -l 4f3f188e-817c-4ee8-86be-40db19f6a075

% sealert -l 619111cc-de7d-4e74-aaf4-6ff9fc0a4c11
Summary
    SELinux is preventing /bin/umount (mount_t) "read write" to socket:[964509]
    (automount_t).

Detailed Description
    [...]
    
Allowing Access
    [...]

Additional Information

Source Context                system_u:system_r:mount_t
Target Context                system_u:system_r:automount_t
Target Objects                socket:[964509] [ unix_stream_socket ]
Affected RPM Packages         util-linux-2.13-0.44.el5 [application]
Policy RPM                    selinux-policy-2.4.6-30.el5
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.catchall
Host Name                     XXX
Platform                      Linux XXX 2.6.18-8.1.1.el5 #1 SMP Mon
                              Feb 26 20:38:02 EST 2007 i686 i686
Alert Count                   1
Line Numbers

Raw Audit Messages

avc: denied { read, write } for comm="umount" dev=sockfs egid=0 euid=0
exe="/bin/umount" exit=0 fsgid=0 fsuid=0 gid=0 items=0 name="[964509]"
path="socket:[964509]" pid=24744 scontext=system_u:system_r:mount_t:s0 sgid=0
subj=system_u:system_r:mount_t:s0 suid=0 tclass=unix_stream_socket
tcontext=system_u:system_r:automount_t:s0 tty=(none) uid=0

The /etc/auto.master ends with a "+auto.master" line and the auto.master map on
YP contains references to both indirect and direct mount maps.
Comment 15 Aleksey Nogin 2007-03-22 14:22:45 EDT
I've filed bug 233481 on the above RHEL 5 issue.

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