| Summary: | _dbus_get_autolaunch_address leaks file descriptors | ||
|---|---|---|---|
| Product: | dbus | Reporter: | Grahame Bowland <grahame> |
| Component: | core | Assignee: | Havoc Pennington <hp> |
| Status: | RESOLVED DUPLICATE | QA Contact: | John (J5) Palmieri <johnp> |
| Severity: | normal | ||
| Priority: | medium | CC: | walters |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Patch to resolve issue by closing all non-necessary FDs in child after fork() | ||
Created attachment 9751 [details] [review] Patch to resolve issue by closing all non-necessary FDs in child after fork() 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...) |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
_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..