This makes sure that extensions can generate code at the expected
places, and change the GDBusInterfaceSkeleton subtype that generated
skeletons derive from.
This allows us to create a copy of an argument without going through
GValue. The codegen here does not have any use for it, but we will add
an extension system in a later commit. The libdex codegen extension will
make use of it to define a boxed type for the method return values.
The out type can be different from the in types in their qualifiers and
thus are not always simply a reference to the in type. However, the out
types used to include the reference instead of the "base" type because
the code generator always used them in places where we actually needed a
reference to the out type (e.g. as out params).
For example, the codegen here generates:
gboolean dex_dbus_ping_pong_call_ping_sync (
DexDbusPingPong *proxy,
const gchar *arg_name,
gchar ** out_pong,
GCancellable *cancellable,
GError **error);
Where `gchar **` is the out type. If we want to codegen a function which
returns the out params in a struct, it would need to look like this:
typedef struct _DexDbusPingPongPingResult
{
gchar * pong;
} DexDbusPingPongPingResult;
Where neither the out type `gchar **` nor the in type `const gchar *` is
appropriate.
This changes the ctype_out to be the base type, and makes the codegen
add the reference explicitly.
A mount table is inherently trusted, so this isn't really a security
issue, but let's not write out of bounds. If anybody is still using GLib
on AIX, then you're welcome.
Discovery and patch credit: mhzcyber - Mohammad Hussam Alzeyyat
(I, Michael, only wrote this commit message and adjusted the
whitespace.)
This adds the condition that a new unix address is tried only when there
is enough space to append random character(s) before the address reach
the length of UNIX_PATH_MAX.
Before this change, creating a GDBusServer with unix addresses longer
than UNIX_PATH_MAX that existed in the filesystem would never return. A
test that expects G_IO_ERROR_ADDRESS_IN_USE in such scenario was added.
If asked to replace a file (i.e. effectively delete and re-create it)
which is a symlink, in a read-only directory, the code would end up
trying to do operations on an invalid `fd`. This was masked when asked
to create a backup, as creating the backup in the read-only
directory would error out just in time.
Make the code a bit more robust in this situation, and add some unit
tests.
Spotted by scan-build.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fallback for non-Linux systems that support the _SC_PHYS_PAGES and
_SC_AVPHYS_PAGES sysconf selectors, such as Solaris & OpenBSD.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Previously the len passed to g_socket_address_new_from_native() was only
for IPv4 addresses and the constructor would fail.
This was reported and discussed here:
fe0139ee98 (note_2581394)
add implementations for these functions using st_{a,c,m}timespec when
__APPLE__ is defined. Also re-enable the g-file-info test for darwin.
Fixes#3070, #2608
`GDBusProxy` implements this interface but allows construction with a
`NULL` interface info and also marks its getter/setter for the interface
info accordingly.
Callers of `g_dbus_interface_get_info()` need to assume that it can
return `NULL` unless they constructed the `GDBusInterface` in a way that
guarantees that the interface info is available.
The connectivity is directly derived from the `is_available` variable,
so if that changes, we need to notify of a change in `connectivity` too.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3803
When a snap is launched from its non-dbus-activable desktop file we may
still need to use the portal to pass the URIs to the program, so that it
can access to them even if confined.
In fact most snaps are not dbus-activable, but they rely on the classic
desktop file activation.
Snap applications like flatpak apps may need to use the portals to open
files, so use the same logic that we have for flatpaks but using the
snap ID that matches portal expectations
We were checking the results of opening an sandboxed application, but
never if the open was actually invoked.
So if another desktop file was used in tests, we were never getting any
failure, at least not related to the lack of a file being opened
Rather than reporting an error via a new `GTask`, report it via the
`GTask` we’ve already created. This avoids a critical warning about
destroying the `GTask` without returning a result.
Also ensure to disconnect the D-Bus signal subscription first, to avoid
an assertion failure in `call_data_free()`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3798
As per commit 0144feb41 the activate action paramter may pack multiple
values but while the behavior was checked we did not check the content
of the values we were receiving in the action callback.
So, also ensure that the variant values we receive are matching the
expectations.
Instead of guessing the portal file name by using the original file name
let's just inspect the portal document ID directory and get the actual
file name
In order to properly test the document portal, let's also create some
dummy files that are named after the FDs we receive and using the
document-id path as the real portal does
When an URI to a symlink is added to the portal, we open it and we send
the FD (of the target) to the portal. This one has no clue about the original
symlink and so it mounts a file that is named like the target.
g_document_portal_add_documents(), however returns a path that contains
the original name and that one is what is sent to the applications when
used via GDesktopAppInfo.
Basically, this is the situation:
- /tmp/symlink -> /tmp/target
- An application is launched to open file:/tmp/symlink
- The portal creates file:/$XDG_RUNTIME_DIR/doc/ID/target
- Gio converts the path to file:/$XDG_RUNTIME_DIR/doc/ID/symlink
Now, since we can't just pass the symlink to the portal without also
changing the logic there, it's just better to do the conversion ourself,
and so, we use the already-opened fd to figure out the real path of the
opened file, and we return a document file URI that uses the target
basename instead
The RFC9110 explanation of HTTP ETags is far superior to
the disjoint ramblings found in (now-obsoleted) RFC2616,
and serves as a much better reference for comparison
with GFile entiity tags. Also, link directly to relevant section.
