The code checked the wrong flags. struct_props is the array of child
properties, so struct_props->flags is the flags of the first child
property. What we need to chech is the flags of the current property,
and if it contains FLATPAK_JSON_PROP_FLAGS_STRICT.
It was accidentally parsed into the product union member but because it
has the same layout as the vendor one, this didn't turn into a bug in
practice, but it probably is UB.
As per g_type_ensure's documentation it is technically incorrect to mark
_get_type fns with G_GNUC_CONST since they have side-effects on their
first run.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/5223 for more
details.
Verify that the file object is valid before checking its cached path
to avoid a potential NULL pointer dereference.
Fixes: c4fce9e4 ("run: Error out if file forwarding of empty paths is attempted")
During a system install with the system helper enabled, the initial
network pull goes to a temporary repo and then via pull local from that
repo to the final system repo while during user install there is only
one pull from network to the final repo.
c672c55 set the logger to use the temporary repo path as installation
but the history command afc87ad since the same day filters the initial
pull out as the installation name will never match the temporary path.
This causes the initial pull operation to be never show up in flatpak
history when using system installs while they work for user installs as
`INSTALLATION=user`.
This is presumably also broken for custom installations as they
will similarly not match the temp repo path.
So don't pass the path at all to flatpak_dir_log and we can later
fall back via flatpak_dir_get_name_cached() which sets the correct
`INSTALLATION` for system installs ie. `INSTALLATION=system`.
This also allows us to remove the workaround of adding two different
expected history outputs from ad1ff6d as both branches log the pull.
Without system helper `flatpak install` needs to be executed as
priviledged to operate on system install so the initial pull was
always logged correctly for that branch.
The file forwarding feature errors out when the path or URI does not
lead to an actual file that can be forwarded. The empty path never
describes an actual file, so we always have to error out.
Without the check, we would get a NULL path from
`flatpak_file_get_path_cached` and crash later.
Closes: #6689
We were handling null properties the same as missing properties
*except* that the MANDATORY flag allowed null properties but
not missing properties. Fix this, so null is disallowed by
MANDATORY.
When checking signatures, the image identity could only have
been NULL if it was null in the input file - so replace a
conditional check on it being non-null with an assertion.
It's legitimate to have manifests listed in an image index that
have no platform object, and hence no architecture - avoid crashing
if we encounter such a manifest.
Mark all properties required by the OCI specification as required;
this eliminates a bunch of cases where we were assuming that
descriptor->digest was non-NULL, and potentially generating
critical errors from g_return_if_fail().
Both collect exports and flatpak_export_dir recursively export the
directories in their respective directory lists. Because of this,
including share/metainfo/releases when share/metainfo is already in the
lists is unnecessary and can cause exporting to fail because of
duplicate files.
Signature downloads can use a different URL from the OCI registry
itself, so they must not depend on TLS options left on the reused curl
handle. Resolve certificates for the URI and pass them explicitly.
Annotating the return as (transfer full) causes bindings to additionally
unref each element on array free, resulting in a use-after-free.
Change the annotation to (transfer container) so bindings know to unref
the array only.
Fixes: https://github.com/flatpak/flatpak/issues/6666
It was solved partially in e0e1b20, but not for completely disallowed code path.
Steps to reproduce:
1. Run any flatpak with explicit --unshare option, e.g:
[user@user-standardpc ~]$ flatpak run --unshare=network --command=bash io.gitlab.librewolf-community
2. Inside flatpak shell spawn any executable:
[io.gitlab.librewolf-community ~]$ flatpak-spawn ls /
Result is:
error: Unknown option --noshare=network
In flatpak_pull_from_oci we can be in in the system helper where we pull
the mirrored OCI image into the system repo. However, to fetch the
signatures in GPG signed repos, we used a remote OciImageSource created
through `flatpak_remote_state_fetch_image_source`. This caused fetching
some data from the registry which we don't want in the deploy method,
and also fails if a token is required to access the repo.
This change fetches the signatures from the mirrored OCI repo instead of
pulling them from the remote OciImageSource. The signatures can come from
anywhere because we verify them against the GPG key in the system repo.
The important bit is the change in `flatpak_pull_from_oci` where we now
pass in the local image_source to fetch the signatures from, and in the
system helper, where we get the right metadata to check the signatures
against (eventually ends up in `flatpak_oci_signatures_verify`).
Being unable to access the system-bus is nto a security boundry since,
in that case it's trivial to start your own session and set
DBUS_SYSTEM_BUS_ADDRESS. This is the same fix as 3afdfd2 but for handling
installation instead. See said commit for more details.
Adapted from #5609Fixes#5076
Co-authored-by: Dan Nicholson <dbn@endlessaccess.org>
/dev/kfd is used for AMD ROCm/OpenCL compute. Add it to the dri
device list so apps can request GPU compute access without
needing --device=all.
Fixes: https://github.com/flatpak/flatpak/issues/5383
I accidentally screwed up the arch I passed to a `flatpak update`
invocation and was very confused as to what actually went wrong. Adding
the actual refs in the commit should help make failure cause more
obvious.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
GTimeVal and g_get_current_time() are deprecated since GLib 2.62
and tv_sec is 32-bit on 32-bit platforms, causing Y2038 overflow.
g_get_real_time() returns gint64 and is safe on all platforms.
polkit_subject_to_string() is called inside the HAVE_LIBSYSTEMD guard
in flatpak_dir_log(), but <polkit/polkit.h> is only included when
USE_SYSTEM_HELPER is defined. This causes a build failure on
configurations that have libsystemd but no system helper.
Guard the polkit call with USE_SYSTEM_HELPER and fall back to "(none)"
so the subject string is always valid for the sd_journal_send() call.
Fixes: f9d5c5c ("dir: Free result of polkit_subject_to_string")
Signed-off-by: Rudi Heitbaum <rudi@heitbaum.com>
If we convert fallback-x11 internally to a conditional x11 permission,
we cannot express current fallback-x11 stacking behavior:
lower: empty + upper: !fallback-x11 -> no x11 access
lower: fallback-x11 + upper: !fallback-x11 -> x11 access
The reason is that conditionals have no view of the lower level.
This changes things in a way that fallback-x11 stays its own socket
permission with two interactions with the x11 socket permission:
* If a upper level resets x11 (--socket=x11, --nosocket=x11), the lower
level fallback-x11 permission gets dropped
* When computing the allowed sockets, --socket=fallback-x11 gets
converted to --socket=if:x11:!has-wayland
Fixes: #6556
Ideally, we would be able to atomically add and remove remotes, but
we're very far from that ideal state. The current behavior is really
suboptimal and leaves the remotes in a inconsistent state if
initialization failed. We can at least make it better by trying to clean
up the half-initialized mess we're currently in. It does however not
protect against SIGKILL-like aborts, as that would require it to be
atomic.
Closes: #6449
Co-authored-by: craftyguy "Clayton Craft" <clayton@craftyguy.net>
If _flatpak_dir_ensure_repo is called with allow_empty=true, it is
allowed to fail to create the repo, and is supposed to return success in
that case.
The system helper handles this correctly, but we then call to
ensure_repo_opened no matter if the repo actuall exists and return an
error when it does not, no matter if allow_empty is set or not.
Closes: #6618
This can be used by apps to restrict access to `--device=usb` by using
the portal and falling back to `--device=usb` if it is not available:
--device-if=usb:!has-usb-portal
Closes: #6557
This can be used by apps to restrict access from `--device=all` to
`--device=usb` in a backwards compatible way:
--device-if=all:!has-usb-device --device=usb
Closes: #6557
This is functionally equivalent to the local child_setup() deleted by
this commit, except that it ignores lseek() errors, which can
legitimately happen when inheriting a non-seekable file descriptor.
Since commit ac62ebe "run: Use O_PATH fds for the runtime and app
deploy directories", any extra-data helper that runs inside a runtime
will receive a non-seekable O_PATH fd as its /usr.
Resolves: https://github.com/flatpak/flatpak/issues/6608
Signed-off-by: Simon McVittie <smcv@collabora.com>
Now that we're passing the app's /app and /usr down to bwrap as O_PATH
file descriptors, it will be even more common to have non-seekable fds
in the array.
Signed-off-by: Simon McVittie <smcv@collabora.com>
These fds are stdin, stdout and stderr respectively, and are expected
to remain open at all times (if they are not needed then they can point
to /dev/null, but they should always be open). If the user gives us
`--env-fd=2` or similar, we don't want to close fd 2 before exiting
unsuccessfully: that would give us nowhere to display the error message.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This was originally in flatpak-portal, then was duplicated into
flatpak-run in commit ac62ebe3 "run: Use O_PATH fds for the runtime and
app deploy directories", and subsequently removed from the portal in
commit 3c500145 "portal: Use --bind-fd, --app-fd and --usr-fd options to
avoid races". Now we want to use it in the portal again.
Helps: https://github.com/flatpak/flatpak/issues/6584
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
On entry to `flatpak run`, these fds have been inheritable (not
FD_CLOEXEC), otherwise they would not have been inherited; but we don't
want the "payload" command to inherit them, so set them as
non-close-on-exec as soon as we receive them. In the cases where we pass
them down to the underlying bwrap command, we'll either dup them, or
set them to be inheritable again (in practice we dup them).
In particular, Chromium-derived web browsers get very upset when their
subsandbox processes inherit unexpected fds, which has been causing crashes
with no useful diagnostic information since CVE-2026-34078 was fixed.
Fixes: 1b5e886d "run: Add --usr-fd and --app-fd options"
Fixes: b5ae89ed "run: Add --(ro-)bind-fd options"
Resolves: https://github.com/flatpak/flatpak/issues/6582
Signed-off-by: Simon McVittie <smcv@collabora.com>
org.freedesktop.Platform.openh264 is one example of an extension that
runs a statically-linked extra-data helper, with no runtime. Only open
the runtime if there is one.
Fixes: ac62ebe3 "run: Use O_PATH fds for the runtime and app deploy directories"
Resolves: https://github.com/flatpak/flatpak/issues/6583
Signed-off-by: Simon McVittie <smcv@collabora.com>
When FlatpakDir runs extra-data helpers in apply_extra_data(),
if the helper is statically linked, it might not need a runtime at all.
For example the helper for openh264 falls into this category.
Fixes: ac62ebe3 "run: Use O_PATH fds for the runtime and app deploy directories"
Helps: https://github.com/flatpak/flatpak/issues/6583
Signed-off-by: Simon McVittie <smcv@collabora.com>
Sebastian Wick