Some programs attempt to use libglib (or even libgio) when setuid.
For a long time, GTK+ simply aborted if launched in this
configuration, but we never had a real policy for GLib.
I'm not sure whether we should advertise such support. However, given
that there are real-world programs that do this currently, we can make
them safer with not too much effort.
Better to fix a problem caused by an interaction between two
components in *both* places if possible.
This patch adds a private function g_check_setuid() which is used to
first ensure we don't run an external dbus-launch binary if
DBUS_SESSION_BUS_ADDRESS isn't set.
Second, we also ensure the local VFS is used in this case. The
gdaemonvfs extension point will end up talking to the session bus
which is typically undesirable in a setuid context.
Implementing g_check_setuid() is interesting - whether or not we're
running in a privilege-escalated path is operating system specific.
Note that GTK+'s code to check euid versus uid worked historically on
Unix, more modern systems have filesystem capabilities and SELinux
domain transitions, neither of which are captured by the uid
comparison.
On Linux/glibc, the way this works is that the kernel sets an
AT_SECURE flag in the ELF auxiliary vector, and glibc looks for it on
startup. If found, then glibc sets a public-but-undocumented
__libc_enable_secure variable which we can use. Unfortunately, while
it *previously* worked to check this variable, a combination of newer
binutils and RPM break it:
http://www.openwall.com/lists/owl-dev/2012/08/14/1
So for now on Linux/glibc, we fall back to the historical Unix version
until we get glibc fixed.
On some BSD variants, there is a issetugid() function. On other Unix
variants, we fall back to what GTK+ has been doing.
Reported-By: Sebastian Krahmer <krahmer@suse.de>
Signed-off-by: Colin Walters <walters@verbum.org>
Many (if not "almost all") programs that spawn other programs via
g_spawn_sync() or the like simply want to check whether or not the
child exited successfully, but doing so requires use of
platform-specific functionality and there's actually a fair amount of
boilerplate involved.
This new API will help drain a *lot* of mostly duplicated code in
GNOME, from gnome-session to gdm. And we can see that some bits even
inside GLib were doing it wrong; for example checking the exit status
on Unix, but ignoring it on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=679691
Call g_simple_async_result_set_check_cancellable() after all
GSimpleAsyncResult creation in order to take advantage of the new
reliable cancellation feature.
The guarantee of reliable cancellation fixes a bug in dbusmenu (which
was already assuming that cancellation was reliable). See this bug:
https://bugs.launchpad.net/ubuntu/+source/libdbusmenu/+bug/953562https://bugzilla.gnome.org/show_bug.cgi?id=672013
Signed-off-by: David Zeuthen <davidz@redhat.com>
Until after we include the glib stuff, so that we have G_OS_UNIX
defined.
For some reason <stdlib.h> pulls in <sys/wait.h> on Fedora so this
wasn't a problem, but many others have reported the issue.
Also add a 'address' G_DBUS_DEBUG option that will print out useful
debug information such as
GDBus-debug:Address: In g_dbus_address_get_for_bus_sync() for bus type `session'
GDBus-debug:Address: env var DBUS_SESSION_BUS_ADDRESS is not set
GDBus-debug:Address: env var DBUS_SYSTEM_BUS_ADDRESS is not set
GDBus-debug:Address: env var DBUS_STARTER_BUS_TYPE is not set
GDBus-debug:Address: Running `dbus-launch --autolaunch=05e508961149264c9b750a4c494aa6f7 --binary-syntax --close-stderr' to get bus address (possibly autolaunching)
GDBus-debug:Address: dbus-launch output:
0000: 75 6e 69 78 3a 61 62 73 74 72 61 63 74 3d 2f 74 unix:abstract=/t
0010: 6d 70 2f 64 62 75 73 2d 77 42 41 6f 4b 59 49 52 mp/dbus-wBAoKYIR
0020: 7a 75 2c 67 75 69 64 3d 30 34 30 64 31 33 66 33 zu,guid=040d13f3
0030: 30 61 30 62 35 32 63 32 30 66 36 32 63 34 31 63 0a0b52c20f62c41c
0040: 30 30 30 30 35 30 38 64 00 d2 38 00 00 01 00 40 0000508d..8....@
0050: 05 00 00 00 00 .....
GDBus-debug:Address: dbus-launch stderr output:
14542: Autolaunch enabled (using X11).
14542: --exit-with-session automatically enabled
14542: Connected to X11 display ':0.0'
14542: === Parent dbus-launch continues
14542: Waiting for babysitter's intermediate parent
14542: Reading address from bus
14542: Reading PID from daemon
14542: Saving x11 address
14542: Created window 88080385
14542: session file: /root/.dbus/session-bus/05e508961149264c9b750a4c494aa6f7-0
14542: dbus-launch exiting
GDBus-debug:Address: Returning address `unix:abstract=/tmp/dbus-wBAoKYIRzu,guid=040d13f30a0b52c20f62c41c0000508d' for bus type `session'
and
GDBus-debug:Address: In g_dbus_address_get_for_bus_sync() for bus type `session'
GDBus-debug:Address: env var DBUS_SESSION_BUS_ADDRESS is not set
GDBus-debug:Address: env var DBUS_SYSTEM_BUS_ADDRESS is not set
GDBus-debug:Address: env var DBUS_STARTER_BUS_TYPE is not set
GDBus-debug:Address: Running `dbus-launch --autolaunch=05e508961149264c9b750a4c494aa6f7 --binary-syntax --close-stderr' to get bus address (possibly autolaunching)
GDBus-debug:Address: dbus-launch output:
0000: 75 6e 69 78 3a 61 62 73 74 72 61 63 74 3d 2f 74 unix:abstract=/t
0010: 6d 70 2f 64 62 75 73 2d 77 42 41 6f 4b 59 49 52 mp/dbus-wBAoKYIR
0020: 7a 75 2c 67 75 69 64 3d 30 34 30 64 31 33 66 33 zu,guid=040d13f3
0030: 30 61 30 62 35 32 63 32 30 66 36 32 63 34 31 63 0a0b52c20f62c41c
0040: 30 30 30 30 35 30 38 64 00 d2 38 00 00 01 00 40 0000508d..8....@
0050: 05 00 00 00 00 .....
GDBus-debug:Address: dbus-launch stderr output:
14549: Autolaunch enabled (using X11).
14549: --exit-with-session automatically enabled
14549: Connected to X11 display ':0.0'
14549: dbus-daemon is already running. Returning existing parameters.
14549: dbus-launch exiting
GDBus-debug:Address: Returning address `unix:abstract=/tmp/dbus-wBAoKYIRzu,guid=040d13f30a0b52c20f62c41c0000508d' for bus type `session'
Note that things work exactly like libdbus, e.g. from the
dbus-launch(1) man page:
Whenever an autolaunch occurs, the application that had to start a
new bus will be in its own little world; it can effectively end up
starting a whole new session if it tries to use a lot of bus
services. This can be suboptimal or even totally broken, depending
on the app and what it tries to do.
[...]
You can always avoid autolaunch by manually setting
DBUS_SESSION_BUS_ADDRESS. Autolaunch happens because the default
address if none is set is "autolaunch:", so if any other address is
set there will be no autolaunch. You can however include autolaunch
in an explicit session bus address as a fallback, for example
DBUS_SESSION_BUS_ADDRESS="something:,autolaunch:" - in that case if
the first address doesn't work, processes will autolaunch. (The bus
address variable contains a comma-separated list of addresses to
try.)
Signed-off-by: David Zeuthen <davidz@redhat.com>
- Fix various #include issues
- Change #error to #warning for the EXTERNAL authentication mechanism.
It is not clear if this should work on Win32 at all.
- Call close() before unlink() for the SHA1 keyring
- Change #error to #warning so we don't forget to do
permission checking of the .dbus-keyrings directory
- Use Win32 SID for the SHA1 auth mech
- Apparently we can't use word 'interface' as an identifier
- Implement a _g_dbus_win32_get_user_sid() function. For now it's
private. Don't know if it should be public somewhere. Maybe in
a future GCredentials support for Win32? I don't know.
- GFileDescriptorBased is not available on Win32. So avoid using
it in GLocalFile stuff. Now, Win32 still uses GLocalFile + friends
(which works with file descriptors) so expose a private function
to get the fd for an OutputStream so things still work.
- Fixup gio.symbols
- Fixup tests/gdbus-peer.c so it builds
With this, at least things compile and the gdbus-peer.exe test case
passes. Which is a great start. I've tested this by cross-compiling on
a x86_64 Fedora 13 host using mingw32 and running the code on a 32-bit
Windows 7 box.
https://bugzilla.gnome.org/show_bug.cgi?id=619142
Signed-off-by: David Zeuthen <davidz@redhat.com>
==6279== 21,615 (4,708 direct, 16,907 indirect) bytes in 169 blocks are
definitely lost in loss record 12 of 13
==6279== at 0x4024D2E: malloc (vg_replace_malloc.c:207)
==6279== by 0x4079A90: g_malloc (gmem.c:135)
==6279== by 0x4079DC8: g_malloc_n (gmem.c:252)
==6279== by 0x4097E66: g_strsplit (gstrfuncs.c:2434)
==6279== by 0x42169A2: g_dbus_address_get_stream_sync
(gdbusaddress.c:875)
Bug #618622.
Things compile and the test-suite passes. Still need to hook up
gio.symbols and docs. There are still a bunch of TODOs left in the
sources that needs to be addressed.
Signed-off-by: David Zeuthen <davidz@redhat.com>
