... and don't spam stderr with exceptions if someone renames things
again.
Last but not least, keep the old names as a fallback, so that LD_PRELOAD
with an older libglib still works.
-Make config.h.win32(.in) have entries that more resembles the generated
config.h.in
-Move the ALIGNOF_* #define's from glibconfig.h.win32(.in) to
config.h.win32(.in), where they were supposed to be.
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>
Also, make it possible to get a 'new ref' on a datalist member
in a race-free way.
This is useful when using object data in thread-safe libraries.
https://bugzilla.gnome.org/show_bug.cgi?id=682849
Because it now handles EINTR. And we should do so. While most people
use Linux, which tries very hard to avoid propagating EINTR back up
into userspace, it can still happen.
https://bugzilla.gnome.org/show_bug.cgi?id=682833
I'd like to use GVariant as a data format in my userspace filesystem,
and having the actual bits be stable means I can reliably compute
cryptographic checksums.
This updated patch removes vardict checks, because Ryan wants the
flexibility to change them in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=673012
This function is causing an insane amount of wasted time on some
real-world profiles and it's pretty useless since we already have
GVariantType (as a type different from a string) for the purpose of
static type safety.
Disable it for now. We can possibly turn this back on again if we solve
bug #544026.
https://bugzilla.gnome.org/show_bug.cgi?id=679835
A parent source holds refs on its children, so if the child source is
destroyed, we need to drop that ref. Fix, and reorganize to make this
all more obvious.
https://bugzilla.gnome.org/show_bug.cgi?id=682560
If a context was freed with sources still attached, those sources
correctly got destroyed, but the corresponding GSourceList structs
were being leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=682560
set_mime_type, set_is_private, add_group, set_groups, set_icon, etc
all added metadata before using it. If set_app_info was called before
any of those it would crash when trying to access the metadata.
We need to have some more discussion on this topic.
This reverts commits 86329ba44fc7662c0bad37955f0ec980a24be495 and
8d40389d15544bdc612989157f80380badce52f7.
https://bugzilla.gnome.org/show_bug.cgi?id=665634
For some time now people have been asking for a way to check for type
compatibility between GVariant instances and format strings. There are
several APIs inside of GLib itself that would benefit from this.
This patch introduces a way to do that.
