18153 Commits

Author SHA1 Message Date
Philip Withnall
c1ded863f0 gobject: Use g_memdup2() instead of g_memdup() in obvious places
Convert all the call sites which use `g_memdup()`’s length argument
trivially (for example, by passing a `sizeof()`), so that they use
`g_memdup2()` instead.

In almost all of these cases the use of `g_memdup()` would not have
caused problems, but it will soon be deprecated, so best port away from
it.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
(cherry picked from commit 6110caea45b235420b98cd41d845cc92238f6781)
2021-07-01 16:05:25 -05:00
Simon McVittie
41baea6887 ghash: Use g_memdup2() instead of g_memdup()
Backport of part of commit 0736b7c1e7cf4232c5d7eb2b0fbfe9be81bd3baa
to the simpler structure of the GHashTable code in glib-2-58.

Helps: #2319
Signed-off-by: Simon McVittie <smcv@collabora.com>
2021-07-01 16:05:25 -05:00
Philip Withnall
8b55fa39a6 glib: Use g_memdup2() instead of g_memdup() in obvious places
Convert all the call sites which use `g_memdup()`’s length argument
trivially (for example, by passing a `sizeof()` or an existing `gsize`
variable), so that they use `g_memdup2()` instead.

In almost all of these cases the use of `g_memdup()` would not have
caused problems, but it will soon be deprecated, so best port away from
it

In particular, this fixes an overflow within `g_bytes_new()`, identified
as GHSL-2021-045 (aka CVE-2021-27219) by GHSL team member Kevin Backhouse.

Adapted for GLib 2.58 by Simon McVittie.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: CVE-2021-27219
Fixes: GHSL-2021-045
Helps: #2319
(cherry picked from commit 0736b7c1e7cf4232c5d7eb2b0fbfe9be81bd3baa)
[Backport to 2.58: Omit changes to ghash.c, will be a separate commit]
[Backport to 2.58: Omit changes to giochannel.c, not needed in this branch]
[Backport to 2.58: Omit changes to uri test, not needed in this branch]
Signed-off-by: Simon McVittie <smcv@collabora.com>
2021-07-01 16:05:25 -05:00
Philip Withnall
54d088f44d gstrfuncs: Add internal g_memdup2() function
This will replace the existing `g_memdup()` function for use within
GLib. It has an unavoidable security flaw of taking its `byte_size`
argument as a `guint` rather than as a `gsize`. Most callers will
expect it to be a `gsize`, and may pass in large values which could
silently be truncated, resulting in an undersize allocation compared
to what the caller expects.

This could lead to a classic buffer overflow vulnerability for many
callers of `g_memdup()`.

`g_memdup2()`, in comparison, takes its `byte_size` as a `gsize`.

Spotted by Kevin Backhouse of GHSL.

In GLib 2.68, `g_memdup2()` will be a new public API. In this version
for backport to older stable releases, it’s a new `static inline` API
in a private header, so that use of `g_memdup()` within GLib can be
fixed without adding a new API in a stable release series.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: CVE-2021-27219
Helps: GHSL-2021-045
Helps: #2319
(cherry picked from commit 5e5f75a77e399c638be66d74e5daa8caeb433e00)
2021-06-23 10:05:44 -05:00
Matthias Clasen
8d8083256b keyfile settings: Use tighter permissions
When creating directories, create them with 700 permissions,
instead of 777.

Closes: #1658
2021-06-23 10:05:44 -05:00
Matthias Clasen
57c5e44fa7 Ensure that the keyfile settings backend exists
We need to bring the type into existence.

Closes: https://gitlab.gnome.org/GNOME/glib/issues/1822
2021-06-23 10:05:44 -05:00
Matthias Clasen
ab4b76b7e0 settings: Tweak priorities for keyfile backend
We want to use the keyfile backend in sandboxes,
but we want to avoid people losing their existing
settings that are stored in dconf. Flatpak does
a migration from dconf to keyfile, but only if
the app explictly requests it.

From an app perspective, there are two steps to
the dconf->keyfile migration:
1. Request that flatpak do the migration, by adding
   the migrate-path key to the metadata
2. Stop adding the 'dconf hole' to the sandbox

To keep us from switching to the keyfile backend
prematurely, look at whether the app has stopped
requesting a 'dconf hole' in the sandbox.
2021-06-23 10:05:44 -05:00
Matthias Clasen
0bc4825443 portal: Add a getter for dconf access
Add method to find whether the sandbox provides
access to dconf. This will be used to tweak
the priorities for the keyfile settings backend.
2021-06-23 10:05:44 -05:00
Matthias Clasen
98f598b665 key file: Handle filename being NULL
This happens when we are default-constructed
without explicit arguments.

Closes: https://gitlab.gnome.org/GNOME/glib/issues/1825
2021-06-23 10:05:44 -05:00
Philip Withnall
484e009b0d gkeyfilesettingsbackend: Add a code comment to clarify things
Signed-off-by: Philip Withnall <withnall@endlessm.com>
2021-06-23 10:05:44 -05:00
Matthias Clasen
491106478b keyfile settings: Accept unquoted strings
It is hard for users to remember that strings have to be explicitly
quoted in the keyfile. Be lenient and accept strings that lack those
quotes.
2021-06-23 10:05:44 -05:00
Matthias Clasen
bb660a7aca settings: Prefer the keyfile backend when sandboxed
When we are in a sandboxed situation, bump the priority
of the keyfile settings backend above the dconf one,
so we use a keyfile inside the sandbox instead of requiring
holes in the sandbox for dconf.
2021-06-23 10:05:44 -05:00
Matthias Clasen
41c3a34a59 settings: Add support for defaults to keyfile backend
Stacked databases and locks are dconf features that allow
management software like Fleet Commander to set system-wide
defaults and overrides centrally for applications.

This patch adds minimal support for the same to the keyfile
backend. We look for a keyfile named 'defaults' and a
lock-list named 'locks'.

Suitable files can be produced from a dconf database with
dconf dump and dconf list-locks, respectively.

The default location for these files is /etc/glib-2.0/settings/.
For test purposes, this can be overwritten with the
GSETTINGS_DEFAULTS_DIR environment variable.

Writes always go to the per-user keyfile.
2021-06-23 10:05:44 -05:00
Matthias Clasen
93d7037dde settings: Register the keyfile backend as extension
This was not done previously because the backend
could not be instantiated without parameters.
2021-06-23 10:05:44 -05:00
Matthias Clasen
a172d82d9a settings: Make the keyfile backend parameterless
Make it possible to instantiate a keyfile settings backend
without specifying parameters, by turning the arguments to
the new() function into construct-only properties. If no
filename is specified, default to
$XDG_CONFIG_HOME/glib-2.0/settings/keyfile
2021-06-23 10:05:44 -05:00
Simon McVittie
d4f0cf25ba credentials: Invalid Linux struct ucred means "no information"
On Linux, if getsockopt SO_PEERCRED is used on a TCP socket, one
might expect it to fail with an appropriate error like ENOTSUP or
EPROTONOSUPPORT. However, it appears that in fact it succeeds, but
yields a credentials structure with pid 0, uid -1 and gid -1. These
are not real process, user and group IDs that can be allocated to a
real process (pid 0 needs to be reserved to give kill(0) its documented
special semantics, and similarly uid and gid -1 need to be reserved for
setresuid() and setresgid()) so it is not meaningful to signal them to
high-level API users.

An API user with Linux-specific knowledge can still inspect these fields
via g_credentials_get_native() if desired.

Similarly, if SO_PASSCRED is used to receive a SCM_CREDENTIALS message
on a receiving Unix socket, but the sending socket had not enabled
SO_PASSCRED at the time that the message was sent, it is possible
for it to succeed but yield a credentials structure with pid 0, uid
/proc/sys/kernel/overflowuid and gid /proc/sys/kernel/overflowgid. Even
if we were to read those pseudo-files, we cannot distinguish between
the overflow IDs and a real process that legitimately has the same IDs
(typically they are set to 'nobody' and 'nogroup', which can be used
by a real process), so we detect this situation by noticing that
pid == 0, and to save syscalls we do not read the overflow IDs from
/proc at all.

This results in a small API change: g_credentials_is_same_user() now
returns FALSE if we compare two credentials structures that are both
invalid. This seems like reasonable, conservative behaviour: if we cannot
prove that they are the same user, we should assume they are not.

Signed-off-by: Simon McVittie <smcv@collabora.com>
2021-06-23 10:05:44 -05:00
Simon McVittie
381594e621 GDBus: prefer getsockopt()-style credentials-passing APIs
Conceptually, a D-Bus server is really trying to determine the credentials
of (the process that initiated) a connection, not the credentials that
the process had when it sent a particular message. Ideally, it does
this with a getsockopt()-style API that queries the credentials of the
connection's initiator without requiring any particular cooperation from
that process, avoiding a class of possible failures.

The leading '\0' in the D-Bus protocol is primarily a workaround
for platforms where the message-based credentials-passing API is
strictly better than the getsockopt()-style API (for example, on
FreeBSD, SCM_CREDS includes a process ID but getpeereid() does not),
or where the getsockopt()-style API does not exist at all. As a result
libdbus, the reference implementation of D-Bus, does not implement
Linux SCM_CREDENTIALS at all - it has no reason to do so, because the
SO_PEERCRED socket option is equally informative.

This change makes GDBusServer on Linux more closely match the behaviour
of libdbus.

In particular, GNOME/glib#1831 indicates that when a libdbus client
connects to a GDBus server, recvmsg() sometimes yields a SCM_CREDENTIALS
message with cmsg_data={pid=0, uid=65534, gid=65534}. I think this is
most likely a race condition in the early steps to connect:

        client           server
    connect
                         accept
    send '\0' <- race -> set SO_PASSCRED = 1
                         receive '\0'

If the server wins the race:

        client           server
    connect
                         accept
                         set SO_PASSCRED = 1
    send '\0'
                         receive '\0'

then everything is fine. However, if the client wins the race:

        client           server
    connect
                         accept
    send '\0'
                         set SO_PASSCRED = 1
                         receive '\0'

then the kernel does not record credentials for the message containing
'\0' (because SO_PASSCRED was 0 at the time). However, by the time the
server receives the message, the kernel knows that credentials are
desired. I would have expected the kernel to omit the credentials header
in this case, but it seems that instead, it synthesizes a credentials
structure with a dummy process ID 0, a dummy uid derived from
/proc/sys/kernel/overflowuid and a dummy gid derived from
/proc/sys/kernel/overflowgid.

In an unconfigured GDBusServer, hitting this race condition results in
falling back to DBUS_COOKIE_SHA1 authentication, which in practice usually
succeeds in authenticating the peer's uid. However, we encourage AF_UNIX
servers on Unix platforms to allow only EXTERNAL authentication as a
security-hardening measure, because DBUS_COOKIE_SHA1 relies on a series
of assumptions including a cryptographically strong PRNG and a shared
home directory with no write access by others, which are not necessarily
true for all operating systems and users. EXTERNAL authentication will
fail if the server cannot determine the client's credentials.

In particular, this caused a regression when CVE-2019-14822 was fixed
in ibus, which appears to be resolved by this commit. Qt clients
(which use libdbus) intermittently fail to connect to an ibus server
(which uses GDBusServer), because ibus no longer allows DBUS_COOKIE_SHA1
authentication or non-matching uids.

Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: https://gitlab.gnome.org/GNOME/glib/issues/1831
2021-06-23 10:05:44 -05:00
Simon McVittie
88cfb7adfa gcredentialsprivate: Document the various private macros
Signed-off-by: Simon McVittie <smcv@collabora.com>
2021-06-23 10:05:44 -05:00
Thomas Jost
8c012e96de gdbus-codegen: honor "Property.EmitsChangedSignal" annotations
Co-Authored-by: Andy Holmes <andrew.g.r.holmes@gmail.com>
2021-06-23 10:05:44 -05:00
Alberts Muktupāvels
2a6de14217 Add a test for per-desktop overrides 2021-06-23 10:03:59 -05:00
Allison Lortie
34feba5a1a glib-compile-schemas: Handle per-desktop overrides
Add a new syntax to override files: if the group name has a ':' in it,
it indicates that we want to override the default values of keys for
only one desktop. For example:

[org.gnome.desktop.interface:Unity]
font-name='Ubuntu 12'

Will override the settings, only if "Unity" is found in
XDG_CURRENT_DESKTOP. Multiple per-desktop overrides can be specified
for a given key: the one which comes first in XDG_CURRENT_DESKTOP will
be used.

https://bugzilla.gnome.org/show_bug.cgi?id=746592
2021-06-23 10:03:59 -05:00
Allison Lortie
4ab36dac09 gsettingsschema: Allow per-desktop overrides
Recognise a new 'd' option in schema keys which gives a dictionary of
per-desktop default values. This dictionary is searched for the items
found in XDG_CURRENT_DESKTOP, in the order. If nothing matches (or if
the option is missing) then the default value is used as before.

This feature was requested by Alberts Muktupāvels and this patch is
based on an approach devised by them.

https://bugzilla.gnome.org/show_bug.cgi?id=746592
2021-06-23 10:03:59 -05:00
Allison Lortie
b011294015 gsettings: cleanup default value lookup
There are a couple of different ways (and soon one more) to access the
default value of a key. Clean up the various places that access this to
avoid duplication.

https://bugzilla.gnome.org/show_bug.cgi?id=746592
2021-06-23 10:03:59 -05:00
Ondrej Holy
4088f3017d gfile: Limit access to files when copying
file_copy_fallback creates new files with default permissions and
set the correct permissions after the operation is finished. This
might cause that the files can be accessible by more users during
the operation than expected. Use G_FILE_CREATE_PRIVATE for the new
files to limit access to those files.
2021-06-23 10:03:59 -05:00
Colin Walters
19e32204f5 build-sys: Pass CFLAGS to $(DTRACE)
Fedora is using https://fedoraproject.org/wiki/Changes/Annobin
to try to ensure that all objects are built with hardening flags.
Pass down `CFLAGS` to ensure the SystemTap objects use them.
2021-06-23 10:03:59 -05:00
Ray Strode
57c9f770be spawn: add shebang line to script
downstream tools get confused when the script is missing a shebang
line, and having a shebang line doesn't hurt, so add one.
2021-06-23 10:03:59 -05:00
Robert Ancell
ef9034d956 codegen: Change pointer casting to remove type-punning warnings
The existing code was generating code with undefined results that modern compilers warn about:

accounts-generated.c:204:23: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
     (GDBusArgInfo **) &_accounts_accounts_method_info_list_cached_users_OUT_ARG_pointers,
2021-06-23 10:03:59 -05:00
Ray Strode
906f65da2a gdbus unix addresses test: don't g_debug when also testing stdout
At the moment the gdbus-unix-addresses test will fail if
G_MESSAGES_DEBUG is set, since the test checks stdout, and the
test has a g_debug call.

This commit drops the g_debug call, which isn't that useful anyway.
2021-06-23 10:03:59 -05:00
Марко Костић
4d478191d9 Update Serbian translation 2019-03-03 10:30:57 +00:00
Serdar Sağlam
d5799dece0 Update Turkish translation 2019-02-12 14:23:51 +00:00
Simon McVittie
d202953c47 Merge branch 'backport-552-gvariant-test-alignment-glib-2-56' into 'glib-2-56'
Backport tests: Allocate gvariant data from the heap to guarantee alignment to glib-2-56

See merge request GNOME/glib!557
2019-01-04 14:14:56 +00:00
Simon McVittie
4ef58e5661 gvariant test: Also force alignment for tuple test data
glib!552 (commit 9eed22b3) fixed this for the tests that failed on i686,
but this additional test failed on Debian's s390x port
(IBM z/Architecture, 64-bit big-endian).

Signed-off-by: Simon McVittie <smcv@collabora.com>
2019-01-04 11:27:05 +00:00
Mart Raudsepp
85c4031696 tests: Allocate gvariant data from the heap to guarantee alignment
On glib-2-58 branch we don't have !455, thus we need aligned data
for the gvariant tests to not fail on i686.

Fixes #1626
2018-12-21 12:05:42 +00:00
Philip Withnall
8723aba598 2.56.4
Signed-off-by: Philip Withnall <withnall@endlessm.com>
2.56.4
2018-12-18 15:03:51 +00:00
Balázs Meskó
c90c012aa5 Update Hungarian translation 2018-12-17 09:22:42 +00:00
Matej Urbančič
d74daea9c8 Updated Slovenian translation 2018-12-02 18:02:29 +01:00
Marek Cernocky
20e5d8c566 Updated Czech translation 2018-11-24 10:10:53 +01:00
Christian Kirbach
1f09e82afc Update German translation 2018-11-15 19:48:29 +00:00
Aurimas Černius
1ca781a2cd Updated Lithuanian translation 2018-11-10 17:46:43 +02:00
Rafael Fontenelle
8f66afc198 Update Brazilian Portuguese translation 2018-11-08 05:51:40 +00:00
Anders Jonsson
c2ff887d72 Update Swedish translation 2018-11-07 18:31:22 +00:00
Philip Withnall
7f68c36f14 Merge branch 'bookmarkfile-self-move-glib-2-56' into 'glib-2-56'
bookmarkfile: Don't move an item if the uri has not changed (backport to glib-2-56)

See merge request GNOME/glib!459
2018-11-06 22:39:22 +00:00
Marco Trevisan (Treviño)
5c6f185e9b bookmarkfile: Don't move an item if the uri has not changed
This was causing a crash, because we were first removing an item, freeing
both the instance itself and the key, and then trying to reuse those.

So, in this case, instead of reassigning an item, we can just return TRUE
as we have already the item at the right place, while it's not needed to
update the modified timestamp, since no modification happened in reality.

Fixes #1588
2018-11-06 17:23:01 -05:00
Marco Trevisan (Treviño)
e46739f18c bookmarkfile: test that moving to the same name works
Verify that we can move a bookmark item to the same name, but actually this
causes a crash right now.
2018-11-06 17:22:55 -05:00
Piotr Drąg
bfd006f439 Update Polish translation 2018-11-06 17:21:16 +01:00
Kukuh Syafaat
2a9979bc38 Update Indonesian translation 2018-11-06 16:18:38 +00:00
Philip Withnall
fe4fd7319f Merge branch '1582-backport-411-422-ossfuzz-fixes-glib-2-56' into 'glib-2-56'
Resolve "Backport GMarkup/GVariant/GDBus fixes to glib-2-58 and glib-2-56" (glib-2-56)

See merge request GNOME/glib!448
2018-11-06 13:11:51 +00:00
Philip Withnall
40c8b41c67 glib: Port various callers to use g_utf8_validate_len()
These were callers which explicitly specified the string length to
g_utf8_validate(), when it couldn’t be negative, and hence should be
able to unconditionally benefit from the increased string handling
length.

At least one call site would have previously silently changed behaviour
if called with strings longer than G_MAXSSIZE in length.

Another call site was passing strlen(string) to g_utf8_validate(), which
seems pointless: just pass -1 instead, and let g_utf8_validate()
calculate the string length. Its behaviour on embedded nul bytes
wouldn’t change, as strlen() stops at the first one.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-11-06 12:07:47 +00:00
Philip Withnall
5fab65270d gutf8: Add a g_utf8_validate_len() function
This is a variant of g_utf8_validate() which requires the length to be
specified, thereby allowing string lengths up to G_MAXSIZE rather than
just G_MAXSSIZE.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-11-06 12:07:47 +00:00
Philip Withnall
b78fb7407a tests: Use g_assert_null() in gdbus-serialization test
This introduces no real functional changes (except when compiling with
G_DISABLE_ASSERT, in which case it fixes the test). Mostly just a code
cleanup.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-11-06 12:07:47 +00:00