Bug 207678
Summary: | Looks like autofs might be leaking an open file descriptor | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Daniel Walsh <dwalsh> | ||||
Component: | autofs | Assignee: | Ian Kent <ikent> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Brock Organ <borgan> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | aleksey, ikent, pgraner | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2006-12-19 19:07:22 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Daniel Walsh
2006-09-22 14:28:19 UTC
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? 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.
Can't you just fcntl(socket, F_SETFL, FD_CLOEXEC); The socket 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. 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? 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? (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 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. (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. 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? (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 (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 (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 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. I've filed bug 233481 on the above RHEL 5 issue. |