GVariant has the concept of fixed-sized types (ie: types for which all
values of the type will have the same size).  Examples are booleans,
integers, doubles, etc.  Tuples containing only these types are also
fixed size.

When GVariant is trying to deal with a fixed-sized value for which it
doesn't have a sufficient backing store (eg: the case where a
fixed-sized value was created with g_variant_new_data() with an
incorrect number of bytes) it denotes this by setting the size of the
value to the correct fixed size but using a NULL data pointer.

This is well-documented in several code comments and also in the public
API documentation for g_variant_get_data() which describes the situation
number which NULL could be returned.

The decision to deal with this case in this way was changed at the last
minute around the time that GVariant was merged -- originally we had an
elaborate setup involving allocating an internal buffer of sufficient
size to be shared between...

gnome-utils git repo was moved to archive/ and this broke the link.

The __FreeBSD__ macro means we have both a FreeBSD kernel and FreeBSD
libc, which isn't the case on GNU/kFreeBSD (GNU libc and userland on
the FreeBSD kernel), so it predefines a different macro. The kernel
is what actually matters for credentials-passing, though.

Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Tested-by: Steven Chamberlain <steven@pyro.eu.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=649302
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581750
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631968


Reviewed-by: Dan Winship <danw@gnome.org>

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 tha...

This reverts commit 18801a9a.

The change to the GIO source filters only applies to the master/2.33.x+
branch as there isn't a gcontenttype-win32.c in glib-2-32, so we still
want to build gcontenttype.c here.

Chun-wei Fan authored Jul 19, 2012 and Colin Walters committed Aug 06, 2012

gcontenttype.c was split into gcontenttype.c and gcontenttype-win32.c
in commit 32192ee9 ("Split gcontenttype.c"), so we don't want to include
gcontenttype.c in the Visual C++ build as it is no longer a source file
meant for Windows.

Thanks to Thomas H.P. Anderson for pointing this out.

Mark Nauwelaerts authored Apr 25, 2012 and Tim-Philipp Müller committed Aug 05, 2012

https://bugzilla.gnome.org/show_bug.cgi?id=674800

Mark Nauwelaerts authored Jul 19, 2012 and Tim-Philipp Müller committed Aug 05, 2012

https://bugzilla.gnome.org/show_bug.cgi?id=674800