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 all invalid values.
Unfortunately, when making this change a small detail was missed.
gvs_tuple_get_child() (the function responsible for deserialising
tuples) was updated to properly check for this case (and it contains a
comment about why it must). gvs_tuple_is_normal() (the function
responsible for verifying if a tuple is in normal form) was not.
We add the check now.
Note that this problem does not exist with any other container type
because tuples are the only container capable of being fixed-sized. All
other container types (arrays, maybes, variants) can contain a variable
number of items or items of variable types (note: we consider dictionary
entries to be two-tuples). The code for validating non-container values
also contains a check for the case of NULL data.
The problem also does not occur in the only other function dealing with
serialised tuples: gvs_tuple_n_children(). Whereas other container
types would have to inspect the serialised data to determine the number
of children, for tuples it can be determined directly from the type.
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>
This reverts commit 18801a9a7b.
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.
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.
String validation was done by checking if the string was valid utf8 and
ensuring that the first non-utf8 character was the last character (ie:
the nul terminator).
No check was actually done to make sure that this byte actually
contained a nul, however, so it was possible that you could have a
string like "hello\xff" with length 6 that would correctly validate.
Fix that, and test it.
