Bug 461943

Summary: leaked file descriptors
Product: [Retired] Red Hat Cluster Suite Reporter: Tim Wilkinson <twilkins>
Component: ccsAssignee: Jonathan Earl Brassow <jbrassow>
Status: CLOSED DUPLICATE QA Contact: Cluster QE <mspqa-list>
Severity: low Docs Contact:
Priority: medium    
Version: 4CC: cluster-maint, dwalsh, edamato, twilkins
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: 2010-01-27 18:17:40 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:

Description Tim Wilkinson 2008-09-11 15:27:02 UTC
Description of problem:

The following selinux flagged events are indicative of leaked file descriptors.

  allow httpd_t initrc_t:unix_stream_socket { read write };
  allow ifconfig_t initrc_t:unix_stream_socket { read write };
  allow netutils_t initrc_t:unix_stream_socket { read write };
  allow ping_t initrc_t:unix_stream_socket { read write };
  allow rdisc_t initrc_t:unix_stream_socket { read write };

I am unsure as to which daemon is starting these apps but it is leaking a file descriptor. After a debug effort with Dan Walsh's assistance, the file descriptor to /var/run/cluster/ccsd.sock is under suspicion.


How reproducible:

Consistent


Steps to Reproduce:

This is reproducible on a 2-node cluster serving web pages with firewall and selinux enforcing.

Comment 1 Tim Wilkinson 2008-09-11 15:32:23 UTC
2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

As I understand it, the following is all that is necessary to prevent the leak ...

   fcntl(fd, F_SETFD, FD_CLOEXEC)

... but I will defer to Dan for the details as to why.

Comment 2 Tim Wilkinson 2008-09-22 15:20:14 UTC
Whatever is starting ifconfig_t, netutils_t, ping_t, and rdisk_t is leaking a file descriptor.

   allow DOMAIN initrc_t:unix_stream_socket { read write };

Check whatever domain is running as initrc_t and make sure all its
descriptors are closed on exec.

   fcntl(fd, F_SETFD, FD_CLOEXEC)

Comment 3 Daniel Walsh 2008-10-29 13:08:08 UTC
ps -eZ | grep initrc_t

What processes is running as initrc_t?

Comment 4 Tim Wilkinson 2008-10-29 14:03:24 UTC
root@et-virt09:~
> ps -eZ | grep initrc_t
system_u:system_r:initrc_t       7216 ?        00:00:00 groupd
system_u:system_r:initrc_t       7224 ?        00:00:00 fenced
system_u:system_r:initrc_t       7230 ?        00:00:00 dlm_controld
system_u:system_r:initrc_t       7236 ?        00:00:00 gfs_controld
system_u:system_r:initrc_t       7331 ?        00:01:58 qdiskd
system_u:system_r:initrc_t       7811 ?        00:00:00 libvirtd
system_u:system_r:initrc_t       7823 ?        00:00:00 rhnsd
system_u:system_r:initrc_t       7875 ?        00:00:44 dnsmasq
system_u:system_r:initrc_t       8095 ?        00:00:00 clurgmgrd
system_u:system_r:initrc_t       8096 ?        00:00:35 clurgmgrd

Comment 5 Daniel Walsh 2008-10-29 16:13:26 UTC
So most likely culprit is clurgmrd.

Comment 6 Lon Hohberger 2010-01-27 18:17:40 UTC

*** This bug has been marked as a duplicate of bug 461954 ***