+++ This bug was initially created as a clone of Bug #248771 +++

Description of problem:
If you have an application which tries to connect to the session bus, but there
is no bus running, the DBus libraries will try to automatically start one. This
appears to be done by spawning dbus-launch. Unfortunately the code does not
appear to close all open file handles after fork()'ing.  So the DBus daemon
inherits all open file handles from the application.

This results in all sorts of very serious badness depending on what the parent
app had open. eg, one app I've hit this with has a number of files open, but
deleted - the intention being that when the app exits all the files are cleaned
up. THis never happens because the auto-spawned daemon keeps the files open. 
The current problem is hitting virt-manager - it has a VNC connection open to a
Xen guest - the DBus daemon inherits this socket file handle so blocks *anyone*
else ever connecting to that guest again.


Version-Release number of selected component (if applicable):
dbus-1.0.2-6.fc7

How reproducible:
Always

Steps to Reproduce:
1. ssh root@some-remote-host
2. Make sure no dbus session bus is running
3. # cat > dbus-demo.py <<EOF
#!/usr/bin/python

log  = open("/tmp/demo.log", "w")

import dbus
import dbus.glib

bus = dbus.SessionBus()
EOF

4. DBUSPID=`ps auxwf | grep dbus-daemon | grep session | awk '{print $2}'`
4.  lsof -p $DBUSPID
  
Actual results:
The dbus daemon has '/tmp/demo.log'  open

Expected results:
The dbus daemon has *no* files open from the parent process.

Additional info:
After forking, the code which autolaunchs the daemon needs to

      open_max = sysconf (_SC_OPEN_MAX);
      for (i = 0; i < open_max; i++)
          close(i);

And then re-open  stdin, stdout & stderr to use  /dev/null.