Bug 10777 - _dbus_get_autolaunch_address leaks file descriptors
Summary: _dbus_get_autolaunch_address leaks file descriptors
Status: RESOLVED DUPLICATE of bug 15947
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: All All
: medium normal
Assignee: Havoc Pennington
QA Contact: John (J5) Palmieri
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-26 19:30 UTC by Grahame Bowland
Modified: 2008-05-30 17:51 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Patch to resolve issue by closing all non-necessary FDs in child after fork() (698 bytes, patch)
2007-04-26 19:30 UTC, Grahame Bowland
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Grahame Bowland 2007-04-26 19:30:22 UTC
_dbus_get_autolaunch_address forks and then executes an external process. It fails to close all open FDs other than those necessary, so arbitrary file handles are leaked through to that child. This is a problem for any application using Bacon single-instance checking; 
eg. open file dialog without a dbus session daemon running
    -> that starts a dbus-launch process which stays about
    -> which has a copy of the bacon filedescriptor, and anything else open
    -> which means bacon thinks the app is still running when you quit

Attached patch fixes this problem. It -should- be portable, as sysconf is POSIX and this is in the sysdeps-unix.c file. Note that as anything else open is also leaked through this may lead to whacky problems, eg. someone's locked file getting leaked through to a dbus process which keeps that lock..
Comment 1 Grahame Bowland 2007-04-26 19:30:59 UTC
Created attachment 9751 [details] [review]
Patch to resolve issue by closing all non-necessary FDs in child after fork()
Comment 2 Havoc Pennington 2007-04-27 06:59:55 UTC
This isn't quite portable I don't think, e.g. on some systems you need to use a function like fdwalk() because the max open fds number is huge. If you look at the g_spawn_ implementation in GLib that will have a solution already.

Of course, the better solution is for apps to set close-on-exec on their fds; libdbus should be doing this for all of its descriptors, so if descriptors are leaked, they should be coming from the app. (unfortunately, somewhere in the mists of time the unix API designers got the default wrong for the close-on-exec flag...)
Comment 3 Colin Walters 2008-05-30 17:51:51 UTC
This one was fixed by a different patch from 15947.

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


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.