Bug 206709 - file descriptor leak in gdm, caught by selinux
file descriptor leak in gdm, caught by selinux
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy-targeted (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
: Desktop
Depends On:
Blocks: 207914
  Show dependency treegraph
Reported: 2006-09-15 16:10 EDT by Suzanne Hillman
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version: 5.0.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-23 02:41:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Suzanne Hillman 2006-09-15 16:10:15 EDT
Description of problem:
There is apparently a memory leak in gdm, as found by selinux complaining about
ypbind and bluez-pin being not allowed to talk to things in gdm (labeled xdm by
selinux) that they believe they ought to be able to talk to (apparently selinux
cleans up file descriptors that are not being owned by anyone anymore).

I don't have a strong sense of what's going on, so please ask dwalsh for more
info (he's cc'd).

Version-Release number of selected component (if applicable):

How reproducible:
Always (or at least on two different machines)

Steps to Reproduce:
1. restart ypbind while logged into X

Actual results:
Get errors in setroubleshoot which look like "SELinux is preventing /sbin/ypbind
(ypbind_t) "use" access to pipe:[12027](xdm_t)"
You may also get errors about bluez-pin, although I do not know how to cause
those, being "SELinux is preventing /usr/bin/bluez-pin (bluetooth_healper_t)
"read" to .gdmHEZ0FT (xd,_tmp_t)"

Expected results:
No such errors.

Additional info:
Comment 1 RHEL Product and Program Management 2006-09-24 18:16:59 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux release.  Product Management has requested further review
of this request by Red Hat Engineering.  This request is not yet committed for
inclusion in release.
Comment 2 Ray Strode [halfline] 2006-09-25 07:55:07 EDT
I'm pretty sure that I fixed this a couple fridays ago after talking to Dan.

Well, the first part of the bug report anyway.  The last part "SELinux is
preventing /usr/bin/bluez-pin (bluetooth_healper_t)
"read" to .gdmHEZ0FT (xd,_tmp_t)" is a bluez-pin bug, I think.
Comment 6 Jay Turner 2006-10-02 10:43:05 EDT
I'm not seeing this error with the 20060927.0 tree, but I haven't seen it in the
first place.  On the same machine I am able to reproduce the bluez-pin error,
however.  So just a datapoint.
Comment 7 Daniel Walsh 2006-10-02 14:53:56 EDT
selinux-policy-2.3.17-1 should fix the bluez-pin problem.
Comment 8 Suzanne Hillman 2006-10-03 13:08:33 EDT
I have not yet had a chance to verify the fix, either, but note that it only
required a restart of ypbind while logged into Gnome to cause it.
Comment 9 Suzanne Hillman 2006-10-04 14:51:25 EDT
Alright, I'm still seeing this on the 20060927.0 tree.

This contains gdm-2.16.0-10.el5 and selinux-policy-2.3.16-2

Is it supposed to be fixed with these packages?
Comment 10 Ray Strode [halfline] 2006-10-04 15:33:31 EDT

* Fri Sep 15 2006 Ray Strode <rstrode@redhat.com> - 1:2.16.0-6.el5
- don't leak pipe fds (bug 206709)

Comment 11 Ray Strode [halfline] 2006-10-04 16:22:33 EDT
Oh, I think I see what's going on...

logfilefd = open_xsession_errors (...);
if G_LIKELY (logfd >= 0) {
    VE_IGNORE_EINTR (dup2 (logfd, 1));
    VE_IGNORE_EINTR (dup2 (logfd, 2));
    VE_IGNORE_EINTR (close (logfd));
VE_IGNORE_EINTR (close (0));
gdm_open_dev_null (O_RDONLY); /* open stdin - fd 0 */
gdm_close_all_descriptors (3 /* from */, -1 /* except */, -1 /* except2 */);
VE_IGNORE_EINTR (execv (argv[0], argv));

So 1) it's closing all the descriptors but stdio/stderr/stdin
   2) we set stdin to /dev/null
   3) we set stdout and stderr to a pipe that gets drained and written to a

So those must be the ones that are showing up in the avc denial messages

Comment 12 Daniel Walsh 2006-10-05 11:15:26 EDT

Chris PeBenito pointed out to me -

There's something here that doesn't compute for me.  When you open up a
gnome-terminal, the shell's fd 0, 1, and 2 should be set to the user's
own pty, replacing the fd 0, 1, and 2 that gnome-terminal itself
inherits from xdm.  So I don't see how a daemon would get it.

So maybe this is a leaked file descriptor from something else in the login chain. 

gdm-binary and Xorg are both labeled xdm_t and any apps that they fork_exec in
the chain to login could also do this.
Comment 13 Daniel Walsh 2006-10-16 10:01:06 EDT
While this is generating AVC Messages this is not a show stopper in that it will
not prevent any activity.   I am reassigning to xdm since this is something in
the login process that is leaking the file descriptor, and it really is not an
SELinux bug.
Comment 14 Ray Strode [halfline] 2006-10-16 11:05:56 EDT
I'm going to tentatively move this to gnome-session since that's the next level
down in the stack and we've already cleared gdm by comment 11.
Comment 15 Ray Strode [halfline] 2006-10-16 12:10:26 EDT
So I talked with Dan a bit about this today.

GDM does a domain transition before execing gnome-session, so a leak from xdm_t
could only happen in gdm or X.  As mentioned in comment 11, gdm is not leaking
because it closes all fds besides the console fds.  

We looked at the open fds in /proc for various processes including
gnome-terminal and bash.  bash only has the console fds and fd 255.  All 4 of
those fds point to the slave end of gnome-terminal's pseudoterminal, so there is
no leak there.

We did see an AVC denial message when running authconfig from the panel.  It was
generated from accessing the console fds.  Dan has already fixed that problem,
though. My selinux-policy was out of date.

The upshot is, this problem is almost certainly already fixed. marking MODIFIED.
Comment 16 Ray Strode [halfline] 2006-10-16 14:11:46 EDT
So I talked to shillman and found out an explaination for comment 12.  She never
ran it from the terminal.  ypbind only got restarted as a side effect of running
Comment 17 Nicole Dai 2006-10-18 06:40:29 EDT
Retested on RHEL5-Client-20061012.9, restart ypbind while logged into X with the
following command:
[root@dhcp-0-179 ~]# service ypbind restart
Shutting down NIS services:                                [FAILED]
Is there something need to be configured to start ypbind?
Comment 18 Ray Strode [halfline] 2006-10-18 10:16:30 EDT
Hi Nicole,  it's not sufficient to run service ypbind restart from a terminal to
reproduce this problem.  Suzanne saw this problem as a side-effect of running
System > Administration > Authentication.   Presumably, she enabled NIS support
for ypbind to have been started by that program, but I'm just guessing.  She'd
have to give reproduction instructions.
Comment 19 Suzanne Hillman 2006-10-18 12:16:41 EDT
I enabled ypbind (using the redhat.com domain), as well as kerberos and
smartcard, using system-config-authentication.

Nicole, I don't know what, if any, ypserver you have where you are, so not sure
what settings you would need to get it to work. Will try to remember to test
tomorrow while in the office.
Comment 20 Suzanne Hillman 2006-10-19 10:10:38 EDT
This is verified as of 20061012.9 tree on i386.
Comment 21 Xiaohong Wang 2006-10-23 02:41:11 EDT
Since it has been fixed already, resolve it.

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