GNOME Bugzilla – Bug 526454
too early use of dbus session bus
Last modified: 2009-03-06 09:39:13 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?
Thinking about it, this is actually a gio bug. Reassigning.
This is with glib2-2.16.2-2.fc9.i386
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 ?
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.
(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.
(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.
Proposal: fall back to local-only if there is no session bus. Does that sound reasonable ?
Created attachment 108833 [details] [review] untested patch Here is an untested patch that may have the desired effect.
Looks good to me (didn't test)
(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.
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 ?
(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.
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.
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?
Created attachment 123019 [details] testcase for g_volume_monitor_get_volumes
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?
http://bugs.freedesktop.org/show_bug.cgi?id=17970
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?
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_ ...
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?
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?
(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.
closing this again, we really don't want to spawn session busses.