After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 526454 - too early use of dbus session bus
too early use of dbus session bus
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gio
1.0.x
Other Linux
: Normal major
: ---
Assigned To: Alexander Larsson
gtkdev
Depends on:
Blocks:
 
 
Reported: 2008-04-06 07:06 UTC by David Zeuthen (not reading bugmail)
Modified: 2009-03-06 09:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
untested patch (540 bytes, patch)
2008-04-08 01:42 UTC, Matthias Clasen
committed Details | Review
testcase for g_volume_monitor_get_volumes (575 bytes, text/plain)
2008-11-19 08:49 UTC, Lin Ma
  Details

Description David Zeuthen (not reading bugmail) 2008-04-06 07:06:47 UTC
I recently upgraded gvfs to version 0.2.2 (in particular the Fedora Package gvfs-0.2.2-1.fc9.i386) from an earlier version (I think 0.2.0 or perhaps earlier). 

The only bit I'm using is g_unix_mount_monitor_new() which in turn just uses a file monitor on local files.

An unfortunate bug has creeped in since then: I'm using gio in a system daemon running as root to monitor files. That daemon listens on a socket. Now, with 0.2.2 when I quit my program an instance of dbus-daemon is lying around

root     15978  0.0  0.0  12956  1024 ?        Ssl  02:50   0:00 /bin/dbus-daemon --fork --print-pid 8 --print-address 10 --session

There's also this process

root     15981  0.0  0.0   6396  1916 ?        S    02:50   0:00 /usr/libexec/gvfsd

This happens because gvfs tries to use the session bus; since my program is running as uid 0 there is no session bus. Thus, libdbus.so is being helpful and spawning a bus. Unfortunately that bus isn't teared down as it should be (I think this is a dbus bug). However, what's worse is that that process inherits file descriptors and the next time I launch my program I can't bind to the socket.

Now, a lot of this are D-Bus bugs. What's a gvfs bug, however, is that we try to connect to the session bus without the application actually requesting use of remote files and/or use of the volume monitoring API. This is very unfortunate for system daemons as every system daemon using even trivial functions from gio (such as file monitoring) will

 - have a local session bus spawned
 - have it's own copy of gvfsd running

   (btw, consider if hald was using trivial functions from gio then
    libgiohal-volume-monitor.so would be loaded that would try to
    talk to hald on initialization => deadlock. Ditto examples for
    Avahi and other system services that the gvfs stack uses)

I can't figure out what change has caused this (by looking at the ChangeLog) but this didn't use to happen.

Of course using GIO_USE_VFS=local is a temporary fix for this. The real fix involves only loading gio modules when we actually use them - the performance hit of loading and initialize a session bus + gvfsd for every system daemon is just too big IMO.

Thoughts?
Comment 1 David Zeuthen (not reading bugmail) 2008-04-06 07:30:40 UTC
Thinking about it, this is actually a gio bug. Reassigning.
Comment 2 David Zeuthen (not reading bugmail) 2008-04-06 07:31:50 UTC
This is with glib2-2.16.2-2.fc9.i386
Comment 3 Matthias Clasen 2008-04-06 13:44:23 UTC
I believe gio loads all modules and then unloads the ones it doesn't need. 
Can you figure the loading of which module causes the dbus connection to be established ?
Comment 4 Alexander Larsson 2008-04-06 17:54:50 UTC
I don't see how this is a gio error. Nothing requires loading a module to initialize a dbus connection. All it needs to do is register the GTypes and the extension points.
Comment 5 David Zeuthen (not reading bugmail) 2008-04-06 20:13:03 UTC
(In reply to comment #4)
> I don't see how this is a gio error. Nothing requires loading a module to
> initialize a dbus connection. All it needs to do is register the GTypes and the
> extension points.

The gvfs modules are indeed loaded

# cat /proc/1423/smaps|grep gvfs
00111000-00135000 r-xp 00000000 08:05 4063517    /usr/lib/gio/modules/libgvfsdbus.so
00135000-00136000 rw-p 00023000 08:05 4063517    /usr/lib/gio/modules/libgvfsdbus.so

This triggers an instance of dbus-daemon to be set up.

root      1428  0.0  0.0  12956  1024 ?        Ssl  16:04   0:00 /bin/dbus-daemon --fork --print-pid 8 --print-address 10 --session

and an instance of gvfsd

root      1431  0.0  0.0   6396  1912 ?        S    16:04   0:00 /usr/libexec/gvfsd

Note how the pids 1423, 1428 and 1431 are close to each other.

So are you saying that the bug is that gvfs initializes a dbus connection too early?

I'm assuming you acknowledge it's a problem that dbus session buses along with gvfsd instances are spawned for every non-session user of gio.
Comment 6 David Zeuthen (not reading bugmail) 2008-04-06 20:23:02 UTC
(In reply to comment #4)
> I don't see how this is a gio error. Nothing requires loading a module to
> initialize a dbus connection. All it needs to do is register the GTypes and the
> extension points.

Here's what happens

 - whenever someone tries to resolve a GFile then all extension points
   for VFS services are initialized

 - Then g_daemon_vfs_init() in gvfs's client/gdaemonvfs.c is called

 - And g_daemon_vfs_init() sets up a D-Bus connection immediately

Wouldn't you agree that we should delay spawning gvfsd (along with setting up a D-Bus connection) until VFS services (e.g. remote files or volume monitoring) is actually needed?

Should probably reassign back to gvfs.
Comment 7 Matthias Clasen 2008-04-07 03:25:51 UTC
Proposal: fall back to local-only if there is no session bus. Does that sound reasonable ? 
Comment 8 Matthias Clasen 2008-04-08 01:42:59 UTC
Created attachment 108833 [details] [review]
untested patch

Here is an untested patch that may have the desired effect.
Comment 9 Alexander Larsson 2008-04-08 08:34:58 UTC
Looks good to me (didn't test)
Comment 10 David Zeuthen (not reading bugmail) 2008-04-08 16:17:50 UTC
(In reply to comment #8)
> Created an attachment (id=108833) [edit]
> untested patch
> 
> Here is an untested patch that may have the desired effect.

I think this is what we need in the short term (didn't test it) but the patch should reference this bug in a TODO comment as it's only fixing the symptoms, not the real problem. 

IOW, I think people expect gio/gvfs to work even if they are not in a session. And I think we want to support that.
Comment 11 Matthias Clasen 2008-04-08 16:33:32 UTC
How exactly do you think people expect it to work in that case ? There is only two possibilities:

either 

- it does spawn a bus and gives you daemonvfs (the current sitatuation)

or 

- it does not spawn a bus and only gives you localvfs (what the patch does)

Am I missing one ?
Comment 12 David Zeuthen (not reading bugmail) 2008-04-08 16:38:01 UTC
(In reply to comment #11)
> Am I missing one ?

 - libgvfsdbus.so only spawns gvfsd when VFS services are actually needed
   (typically for volume monitoring or when encountering URI's != file:///)

e.g. what I said in comment 6.
Comment 13 Matthias Clasen 2008-04-16 03:09:28 UTC
2008-04-15  Matthias Clasen  <mclasen@redhat.com>

        Bug 526454 – too early use of dbus session bus

        * client/gdaemonvfs.c (g_io_module_load): Refuse to load if
        there is no session bus.

Comment 14 Lin Ma 2008-11-19 08:48:17 UTC
Hello DBus and GVFS gurus,

Could you take a look at volume monitor issue which is a result of this fix. The problem is if a privilege up process requires get volumes from g_volume_monitor, by the fix it will fail back to localvfs which reads volume info from fstab/vfstab instead of HAL then obtains a wrong volumes.

A test case is attached, tested on ubuntu/sudo and solaris/pfexec (on the latter, unset DBUS_SESSION_BUS_ADDRESS to test). Does anyone has any better solution, it's really a serious bug I think. Any comments or suggestions?
Comment 15 Lin Ma 2008-11-19 08:49:45 UTC
Created attachment 123019 [details]
testcase for g_volume_monitor_get_volumes
Comment 16 Alexander Larsson 2009-02-25 15:26:58 UTC
I don't like leaking a dbus session daemon running as root like this (it won't quit when the app quits). Why does sudo etc clear the DBUS_SESSION_BUS_ADDRESS env var? Ideally we should be able to use the users normal session bus, or is that a bad idea?
Comment 17 Colin Walters 2009-02-25 15:32:12 UTC
http://bugs.freedesktop.org/show_bug.cgi?id=17970
Comment 18 Lin Ma 2009-02-26 08:06:59 UTC
I think it's the time to remove this patch, because dbus is able to auto-spawn a session bus and try to reuse that session bus correctly (at least for local X session). Any comments?
Comment 19 Matthias Clasen 2009-02-27 22:18:34 UTC
The patch is about avoiding to auto-spawn a session bus.
So I don't see how you can argue that we should drop it _because dbus is able to auto-spawn_ ...
Comment 20 Lin Ma 2009-03-03 05:55:05 UTC
Hmm, sorry I didn't speak clearly. I know the patch is about avoiding to auto-spawn. But the normal requests which come by g_volume_* functions are also blocked (see my comment#14). The key problem is the fail back local module can't give function caller a correct result.

There are several solutions for that issue:
1. The best one, spawn dbus only need, e.g. g_volume_* functions.
2. Remove this patch, I think the result is that only one dbus session is spawned per user and X session with the fix mentioned in comment #17. If the performance lost is OK for you, then this one is the cheaper one.
3. Enhance gio local module, it could be hard.

Any comments?
Comment 21 Alexander Larsson 2009-03-04 12:17:59 UTC
Lin: I don't understant why you think its ok to spawn dbus for some functions and not others?

I think autospawning is a bad idea, as it will cause leaked dbus sessions that will live forever. 

And i'm not even sure it will work. Will the various daemons spawned by gvfs really share the autospawned session dbus?
Comment 22 David Zeuthen (not reading bugmail) 2009-03-04 12:57:21 UTC
(In reply to comment #20)
> Hmm, sorry I didn't speak clearly. I know the patch is about avoiding to
> auto-spawn. But the normal requests which come by g_volume_* functions are also
> blocked (see my comment#14). The key problem is the fail back local module
> can't give function caller a correct result.
> 
> There are several solutions for that issue:
> 1. The best one, spawn dbus only need, e.g. g_volume_* functions.
> 2. Remove this patch, I think the result is that only one dbus session is
> spawned per user and X session with the fix mentioned in comment #17. If the
> performance lost is OK for you, then this one is the cheaper one.
> 3. Enhance gio local module, it could be hard.
> 
> Any comments?

1. and 2. won't happen, we really don't want to spawn a bus for reasons mentioned upthread. Also keep in mind that this bug is about avoiding spawning a session bus for system daemon. And since this is indeed fixed, for a long time even, we should just close this bug already.

What you are talking about isn't really a bug in gio/gvfs; what you want can be fixed in

 1. sudo/pfexec (avoid clearing DBUS_SESSION_BUS_ADDRESS)
 2. dbus-daemon (allow e.g. uid 0 to connect to the bus)

as Alex already said in comment 16. Also consider why DBUS_SESSION_BUS_ADDRESS is cleared in the first place.

Of course, my view is that what you want is just fundamentally wrong. E.g. if you need privileged processes to require access your desktop session (such as the the X server or session message bus), then 99% of the time it means that someone is doing something wrong.

Look at http://www.gtk.org/setuid.html got some reasons why you don't want this for GTK+ programs. For GIO/GVfs (which has no UI) there are at least two other reasons

 - passwords retrieved/stored by GVfs backends will be via the users keyring. This
   may be unwanted; I mean you probably authenticated as root to start your
   program so uid 0 may unwillingly be storing passwords in the unprivileged
   users keyring.

 - the data you are accessing can be served by code running as the user (mount
   daemons); you fundamentally can't trust this data since it runs as an unprivileged
   user

Anyway, life is probably only going to get harder for such applications, see 
http://bugs.freedesktop.org/show_bug.cgi?id=17970#c20 for some thoughts on how we should treat them.

So you may want to reconsider if this is really what you want.

Comment 23 Alexander Larsson 2009-03-06 09:39:13 UTC
closing this again, we really don't want to spawn session busses.