If the $HOME environment variable is set, prefer that to the entry in
/etc/passwd.
This brings us in line with almost every other utility and library on
UNIX-like systems while avoiding some of the more complicated
possibilities that have been suggested.
This incompatible change has been petitioned for quite some time by
many, and in particular from the Debian world, which carries a patch
that adds a new G_HOME environment variable with the same meaning as
this patch now assigns to HOME.
The primary motivation for the change was to increase the testability of
GLib-based programs from 'make check' types of frameworks: it is now
possible to set HOME to a temp directory to avoid the testsuite
modifying the user's real home directory.
The change also brings us increased compliance with the XDG Base
Directory Specification. The specification specifically states that the
default values should be computed based on the HOME environment
variable, whereas we were basing them on the value from /etc/passwd.
The change was agreed to by all in attendence at the November 29 Gtk+
developer meeting.
https://bugzilla.gnome.org/show_bug.cgi?id=142568
The GLib units policy used to be that 'KB' means 1024 bytes, 'MB' means
1024 KB, 'GB' means 1024 MB, etc.
Those days are over, but we have a deprecated function that still works
that way. It contains the string "KB", marked for translation, which
has been a source of confusion for translators on multiple occasions.
https://bugzilla.gnome.org/show_bug.cgi?id=687516
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>
We handle a special case for G_USER_DIRECTORY_DESKTOP
when we init the values but drop it when we reload them.
Fix this by preferring old values to NULL
https://bugzilla.gnome.org/show_bug.cgi?id=676594
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
-Move _glib_get_locale_dir to ggettext.c, as Matthias suggested
-Made up for the headers that needed to be included in ggettext.c to avoid
C4013 (implicit declaration of ...) errors/warnings
Split win32 functions off into their own section, instead
of having large and unwieldy ifdef sections inside each function.
Also move the compat versions of env functions over from gutils.c
gutils.[hc] is a bit of a grab bag, so lets start cleaning
things up by moving all the environment-related functions
into separate genviron.[hc] files.
The private _g_getenv_nomalloc has been moved to its sole caller.
When spawning a child process, it is not safe to call setenv() before
the fork() (because setenv() isn't thread-safe), but it's also not
safe to call it after the fork() (because it's not async-signal-safe).
So the only safe way to alter the environment for a child process from
a threaded program is to pass a fully-formed envp array to
exec*/g_spawn*/etc.
So, add g_environ_getenv(), g_environ_setenv(), and
g_environ_unsetenv(), which act like their namesakes, but work on
arbitrary arrays rather than working directly on the environment.
http://bugzilla.gnome.org/show_bug.cgi?id=659326
Make sure that it calls absolutely nothing that may ever recurse back
into GLib again:
- g_ascii_strcasecmp() is unsafe because it has g_return_if_fail() at
the top. As far as I know, the only ASCII character letter that
would get special treatment here is "i" and that appears in neither
"help" nor "all".
- g_getenv() is very complicated on Windows, so use a simple version
that is sufficient for our purposes.
Now that it's completely safe, we can just call it from g_logv() in the
usual way without all of the hacks.
https://bugzilla.gnome.org/show_bug.cgi?id=660744
Do a substantial rework of the GMutex and GCond APIs.
- remove all of the macro indirection hackery which is no longer needed
since we dropped support for switchable thread implementations
- expose the structure types and add G_MUTEX_INIT and G_COND_INIT
static initialiser macros
- add g_mutex_init() and g_mutex_clear() for use when embedding GMutex
into another structure type and do the same for GCond as well
- avoid infinite recursion hazards by ensuring that neither GCond or
GMutex ever calls back into any other part of GLib
- substantially rework the Windows implementation of GCond and GMutex
to use the SRWLock and CONDITION_VARIABLE APIs present on Windows
2008/Vista and later, emulating these APIs on XP
Remove the explicit thread initialisation functions for g_get_charset(),
g_get_filename_charsets() and g_get_language_names().
Add a lock around one remaining case of access to libcharset (the other
2 cases already have the lock).
Do a proper g_once_init_enter() style initialisation for the GLib
gettext functions.
https://bugzilla.gnome.org/show_bug.cgi?id=658683
Fix various (out) arguments, (allow-none) and (array zero-terminated=1)
for g_spawn_*() and some others.
Some additional fixes by Colin Walters <walters@verbum.org>
https://bugzilla.gnome.org/show_bug.cgi?id=646635
* Since the GLib translations are lazily initialized, we need an
internal wrapper for g_dpgettext() that does the initialization
in the same way as glib_gettext()
* We need to use the glib domain defined by GETTEXT_PACKAGE
rather than than the application's domain.
https://bugzilla.gnome.org/show_bug.cgi?id=644607
