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.
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.