In the case that the "HOME" environment variable is set (as it is under
normal circumstances), we don't really need to be opening /etc/passwd.
For historical reasons (ie: how we used to ignore $HOME) and due to the
grouping of many unrelated things together (reading username, hostname,
home directory, tmpdir, etc.) into one function we were still opening
/etc/passwd in g_get_home_dir(), even if $HOME was set.
Since earlier commits removed code from it, all that remains in
g_get_any_init_do() is the logic for dealing with $HOME and reading the
password database.
We now split the logic to deal with $HOME into g_get_home_dir(). With
only the password database functionality remaining, g_get_any_init_do()
is renamed to g_get_user_database_entry() and modified not to set global
variables but rather return a struct. If g_get_home_dir() cannot find
$HOME, it falls back to calling g_get_user_database_entry() and using
the home directory from there.
Use of the 'g_utils_global' lock is further reduced by using
g_once_init_enter() to protect the critical sections in each of
g_get_user_database_entry() and g_get_home_dir().
Finally, the g_get_user_name() and g_get_real_name() functions are
modified to use the new regime.
https://bugzilla.gnome.org/show_bug.cgi?id=693204
Some code was directly calling g_get_any_init() and then expecting to be
able to use the static 'g_home_dir' variable directly. Change these
over to g_get_home_dir() instead.
https://bugzilla.gnome.org/show_bug.cgi?id=693204
This is a source-compatible change and only breaks ABI with respect to
truly ancient binaries (and those binaries are already broken for other
reasons).
Back in the day, functions like g_get_user_name() used to return strings
in the system codepage instead of utf8 (as they do today).
It was decided at some point to change these functions to return utf8,
breaking source compatibility but keeping ABI compatibility. This was
done by exporting new symbols with names like g_get_user_name_utf8() and
using a #define of the old name over to the new name (so that newly
compiled code would link against the _utf8 version, but old binaries
would continue to use the non-utf8 variant).
Meanwhile, glib has undergone several ABI breaks on Windows since, so
those old binaries don't work anymore.
Start to clean up this mess by removing the #define renaming. New
binaries calling g_get_user_name() will now link against
g_get_user_name() and it will return utf8.
We must keep the functions like g_get_user_name_utf8() for binary
compatibility with recently built programs (ie: ones built with the
renaming). Nobody should have ever been calling these directly and of
course they can return utf8, so just add them as internal wrappers in the
.c file and declare them _GLIB_EXTERN there.
One day, if we feel like breaking Windows ABI again, we can finish the
cleanup by dropping the wrappers. There is some talk of introducing
something like 'ABI compatible for two years' and this change would be
compatible with such a regime.
https://bugzilla.gnome.org/show_bug.cgi?id=693204
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
