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): gdm-2.16.0-5.el5 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:
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.
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.
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.
selinux-policy-2.3.17-1 should fix the bluez-pin problem.
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.
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?
Yes. * Fri Sep 15 2006 Ray Strode <rstrode> - 1:2.16.0-6.el5 - don't leak pipe fds (bug 206709)
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 ~/.xsession-errors So those must be the ones that are showing up in the avc denial messages
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.
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.
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.
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.
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 authconfig.
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?
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.
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.
This is verified as of 20061012.9 tree on i386.
Since it has been fixed already, resolve it.