g_settings_backend_watch() uses a weak notify for keeping track of
the target. There's an explanation why this is supposed to be safe but
that explanation is wrong.
The following could happen before:
1. We have the target stored in the watch list
2. The last reference to the target is dropped in thread A and we end up
in g_settings_backend_watch_weak_notify() right before the mutex
3. g_settings_backend_dispatch_signal() is called from another thread B
and gets the mutex before 2.
4. g_weak_ref_init() is called on the target from thread B, which at
this point has a reference count of exactly one (see g_object_unref()
where it calls the weak notifies)
5. Thread A continues at 3. and drops the last reference and destroys
the object. Now the GWeakRef from 4. points to a destroyed object. Note
that GWeakRefs would be cleared before the weak notifies are called
6. At some later point another thread g_weak_ref_get() is called by
g_settings_backend_invoke_closure() and accesses an already destroyed
object with refcount 0 from the GWeakRef created in 4. by thread B (or
worse, already freed memory that was reused).
Solve this by actually storing a GWeakRef of the target in the watch
list and only access the target behind it via the GWeakRef API, and then
pass a strong reference to the notification dispatch code.
The weak notify is only used to remove the (potentially with empty
GWeakRef) target from the list of watches and the only place that
compares the target by pointer instead of going through the GWeakRef
API.
Fixes https://gitlab.gnome.org/GNOME/glib/issues/1870
If we fail to create a GWinhttpFile for a URI (for example, because it’s
an invalid URI or is badly encoded), don’t just return NULL. Instead,
fall back to the wrapped VFS which might be able to handle it instead.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1819
It can return NULL if the URI was badly encoded or couldn’t be handled
by Windows’ API.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1819
It cannot return a NULL value, as none of its callers have error
handlng. Add an assertion to check the values returned by the VFS
implementations.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1819
The event source used to handle inactivity_timeout doesn't hold a
reference on the application. Therefore, it is possible for callback
function of the event source to run after the application has been
freed, leading to use-after-free problem. To avoid the problem, we
should remove the event source before the application is freed.
This should fix SIGBUS crash of gio/tests/gapplication on FreeBSD.
https://gitlab.gnome.org/GNOME/glib/issues/1846#note_566550
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.
It's somewhat unrealistic to use a GDBusServer without a
GDBusAuthObserver, because most D-Bus servers want to be like the
standard session bus (the owning user can connect) rather than being
like the standard system bus (all users can connect, the server is a
security boundary, and many bugs are security vulnerabilities).
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is simpler and more robust than DBUS_COOKIE_SHA1, which relies
on assumptions about random numbers and a secure home directory.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Authentication is about proving who I am; authorization is about
whether, given the knowledge of who I am, I am allowed to do something.
GDBusServer and GDBusConnection carry out authentication automatically,
but rely on the library user to carry out authorization.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is useful information for implementors of portable software to know
whether they can rely on credentials-passing.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Add a case for when the IPv6 result comes back negative and the IPv4
result is significantly delayed. This is exactly the case that causes
the bug addressed by GNOME/glib!865
The "happy eyeballs" RFC states that on receiving a negative response
for an IPv6 address lookup, we should wait for the IPv4 lookup to
complete and use any results we get from there.
The current code was not doing that: it was rather setting a timeout for
failing the resolution entirely. In scenarios where the IPv4 response
comes more than 50ms after the IPv6 response (which is easily attainable
under valgrind in certain configurations) this means that the IPv4
response will never come.
Remove the timeout and just wait.
See merge request GNOME/glib!865
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.
`NM_STATE_CONNECTED_SITE` is documented to mean that a default route is
available, but that the internet connectivity check failed. A default
route being available is compatible with the documentation for
GNetworkMonitor:network-available, which should be true if the system
has a default route for at least one of IPv4 and IPv6.
https://developer.gnome.org/NetworkManager/stable/nm-dbus-types.html
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1788
(cherry picked from commit e37f0cbd89)
The parent GNetworkAddress contains a shared list of resolved
addresses that is used as a cache for multiple enumerations.
This commit ensures that the cache is only set upon completion of
DNS lookups and only read once by enumerations to avoid being in a
bad state.
Fixes#1771
We miss releasing the async operation's reference on a state object in
one of the error cases.
The call to connection_attempt_remove() (although it calls unref
internally) is not sufficient because this is releasing the reference
that the list owns.
Closes#1774
The network-available property can be asserted by querying the NMState
describing the current overval network state, instead of the
NMConnectivityState. The advantage of the NMState is that is reflects
immediately the network state modification, while the connectivity
state is tested at a fixed frequency.
This introduces no functional changes, but combines two duplicated lists
and makes the meson.build file a little easier to follow.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1711
Closes: https://gitlab.gnome.org/GNOME/glib/issues/1566
Short names were used in win32 implementation to allow launching
on installations where full path to libgio-2.0-0.dll contain spaces.
However, short names are optional on windows: so if they were disabled
that method fails - see issue linked above.
Since rundll32 doesn't support neither spaces, nor quotes in cmdline
this patch changes rundll32 argument to just .\gio-dll-name.dll
and uses the entire path directory containing gio dll as rundll32
current directory.
Added comments informing about potential subtleties discovered during
writing test for gdbusaddress on win32.
There are not known to have real-world user-visible effect,
so by now I'm only adding comments without creating issues.
nm_conn_to_g_conn already handles UNKNOWN like NONE (returning
G_NETWORK_CONNECTIVITY_LOCAL in both cases). So in sync_properties
we should also set new_connectivity to G_NETWORK_CONNECTIVITY_LOCAL
for both NM_CONNECTIVITY_UNKNOWN and NM_CONNECTIVITY_NONE.
This has the added benefit that when NetworkManager returns the network
connectivity is UNKNOWN, we set network_available to FALSE as it should
be. Previously, there were cases in a laptop with no network access,
that g_network_monitor_get_network_available returned true, which was
wrong and is also fixed with this commit.
If using the --interface-info-{body,header} options to gdbus-codegen,
and the first interface to be outputted has no methods, but does have
properties or signals, an uninitialised variable would be used for the
property/signal ‘since’ values.
In other situations, the ‘since’ value for a prior method would have
been incorrectly used for the properties/signals.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Implement the approach suggested in
https://gitlab.gnome.org/GNOME/glib/merge_requests/276
1. Try to open O_RDWR. On success, pass that fd
2. If EACCESS => fail the trash op, we "need" read-write to successfully trash it
3. If EISDIR => re-open the fd with O_PATH, and pass that (which will fail on snap,
but verify the dir for flatpaks)
Don’t pollute the build directory with files generated by running the
test.
Note that there are still other tests in the gsettings.c test suite
which use the build directory, but fixing them is a bit more involved
than I have time for right now. This is a step in the right direction.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
