This adds a new type that is meant to track more complex permissions
than a pure bitmask, including conditional dependencies. It is not yet
used, but it will be used for at least the socket and device
permissions.
For each possible permission we track whether the permission is
unconditionally allowed, unconditionally disallowed, or if it is
conditionally allowed (allowed if some conditions are met).
Additionally we track for each permission whether stacking the context
on top of another will reset permissions in the layer below. This is a
new feature, because previously merging layers *always* overrode the
value from below, whereas conditional permissions can either stack on
top of, or replace the underlying layer.
In terms of the keyfile, there are 4 possible types of layers:
1) Add a permission, removes all partial permissions below
socket=pipewire
2) Remove access, removes both partial and full permissions below
socket=!pipewire
3) Adds a partial permission, keeping whatever is already there:
socket=pipewire;pipewire:if:has-wayland
Note: This adds a plain `pipewire` for backwards compat.
Note: If parent has full pipewire access, this is a no-op.
4) Adds a partial permission, remove all previous access
socket=!pipewire;pipewire;pipewire:if:has-wayland
Note: This seems weird as it has both !pipewire and pipewire, but older versions
will read these in order and get the right result.
Additionally, partial permissions can have multiple conditions:
socket=pipewire;pipewire:if:has-something;pipewire:if:has-other;
In such a case the socket will be accessible if any condition matches.
Conditions can also be negated:
socket=pipewire;pipewire:if:!has-something;
Due to backwards compatibility we have to add the non-conditional
permission as well as the conditional, as older flatpak will ignore
the conditional. This is handle when serializing/deserializing the
permissions, and internally we don't have to care about this.
Instead of pulling out data from the context and passing it to the
function. This allows to make further changes to the function which
require more data from the context.
This moves the allocation of the GPtrArray to the caller which will
become useful in a future commit because another function can add more
elements to the same array.
If the internal_tests option is enabled we build some internal tests
into the binary. These are added to the tests we run in testlibrary.
This is not intended to be enabled in production, as it adds size to
the real binary, but is useful for CI and development.
This makes it possible to pass arguments to g_test_init via mesons
--test-args. This can be useful when one wants to run a single test with
`meson test testlibrary --test-args='-p /context'.
This will pass the exact appstream component ID to copy_icon
This was introduced in 7dd92d8a9b to
handle appstream component IDs that ended in two `.desktop` suffixes.
Recent analysis of appstream data shows that at least on Flathub no such
appstream cid exist anymore and Telegram now has component ID
`com.telegram.desktop`.
With the switch to libappstream, appstreamcli-compose produces icons in
`share/app-info/flatpak` named by the appstream component ID instead of
the `$FLATPAK_ID` used by appstream-glib. This causes applications whose
`$FLATPAK_ID` does not end with `.desktop` but their appstream-component
ID ends in `.desktop` ie. `$FLATPAK_ID != appstream-cid` to loose icons
from the appstream ostree ref as `copy_icon` was being fed the id
without `.desktop` but icons were created by appstreamcli
with `.desktop` in them.
This will avoid adding anymore ID heuristics/workarounds on either side,
per the discussion in [1].
An application with the `$FLATPAK_ID` `com.telegram.desktop` and the
appstream ID `com.telegram.desktop.desktop` will be broken with this
change but such dual `.desktop` IDs are non existent and should be fixed
individually or be blocked on an app store level.
[1]: https://github.com/flathub/flathub/issues/4222
Instead of clearing the environment that we spawn the flatpak executable
with, we use the new --clear-env. For environment variables that we
inherit from the calling instance, we append them as arguments after the
--clear-env so it starts from a clean slate.
Closes: https://github.com/flatpak/flatpak/issues/5271
Upstream/vendor configuration files should be installed under /usr/,
so that local users/admins can install overrides in /etc/.
Distributions like Ubuntu are already manually configuring this,
so just make it the default.
Fixes c75ba1c7e1
```
In file included from /usr/lib/aarch64-linux-gnu/glib-2.0/include/glibconfig.h:9,
from /usr/include/glib-2.0/glib/gtypes.h:34,
from /usr/include/glib-2.0/glib/galloca.h:34,
from /usr/include/glib-2.0/glib.h:32,
from /usr/include/glib-2.0/gobject/gbinding.h:30,
from /usr/include/glib-2.0/glib-object.h:24,
from /usr/include/glib-2.0/gio/gioenums.h:30,
from /usr/include/glib-2.0/gio/giotypes.h:30,
from /usr/include/glib-2.0/gio/gio.h:28,
from ../common/flatpak-utils-http.c:23:
In function ‘glib_autoptr_clear_GFileEnumerator’,
inlined from ‘glib_autoptr_cleanup_GFileEnumerator’ at /usr/include/glib-2.0/gio/gio-autocleanups.h:69:1,
inlined from ‘flatpak_get_certificates_for_uri’ at ../common/flatpak-utils-http.c:284:34:
/usr/include/glib-2.0/glib/gmacros.h:1361:10: warning: ‘enumerator’ may be used uninitialized [-Wmaybe-uninitialized]
1361 | { if (_ptr) (cleanup) ((ParentName *) _ptr); } \
| ^
/usr/include/glib-2.0/glib/gmacros.h:1379:3: note: in expansion of macro ‘_GLIB_DEFINE_AUTOPTR_CLEANUP_FUNCS’
1379 | _GLIB_DEFINE_AUTOPTR_CLEANUP_FUNCS(TypeName, TypeName, func)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/gio/gio-autocleanups.h:69:1: note: in expansion of macro ‘G_DEFINE_AUTOPTR_CLEANUP_FUNC’
69 | G_DEFINE_AUTOPTR_CLEANUP_FUNC(GFileEnumerator, g_object_unref)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
../common/flatpak-utils-http.c: In function ‘flatpak_get_certificates_for_uri’:
../common/flatpak-utils-http.c:284:34: note: ‘enumerator’ was declared here
284 | g_autoptr(GFileEnumerator) enumerator;
```
Adapted from: https://github.com/flatpak/flatpak/pull/6125
In systemd v259, /run/host/root will be a documented location
for bind mounting the host's root filesystem into a
container. Ref: https://github.com/systemd/systemd/pull/38384
host-root is the sledgehammer permission for file browsers
and similar apps that the user might want to give full access
to.
This works same as the existing host keywords by mounting into
/run/host/root. applications will need adjustments to essentially
treat that path as "root".
Since this opens the door to all sorts of malicious software, the
permission should be put under tight review in flatpak
repositories.
Resolves: #5723
Co-authored-by: Ryan Brue <ryanbrue.dev@gmail.com>
Xe module supports the discrete and new integrated GPUs (the Arc series) and
the i915 supports the older Intel integrated GPUs (Intel HD).
Closes: https://github.com/flatpak/flatpak/issues/5248
Fixes#2489
Adds and wires up a `reinstall` option to
`flatpak_dir_install_bundle`. Previously, bundle install
transactions would silently drop the reinstall flag.
Instead of using flatpak_oci_manifest_descriptor_get_ref which requires
the `org.opencontainers.image.ref.name` annotation, get any valid
manifest, and make sure to return NULL if there are multiple valid
manifests.
Closes: https://github.com/flatpak/flatpak/issues/6081
Since flatpak_image_source_new_remote() already tries to load files
from the registry, having a separate flatpak_image_source_set_token()
doesn't work - when the token is set, it's already too late to
be passed along with the initial requests.
The F_DUPFD and its relative F_DUPFD_CLOEXEC both expect an int argument
as extra argument, being the minimal value for the new FD. This argument
must be within the accepted range (see ulimit -H -n).
This was detected in Ubuntu during testing against the latest glibc,
stracing resulted in:
107244 fcntl(1, F_DUPFD_CLOEXEC, 1847846346272) = -1 EINVAL (Invalid argument)
On the system in question (ppc64el machine running Ubuntu Questing), the
relevant limit is 524288.
For the fix we use 3 as a reasonable floor value, as in the first one
after stderr. It also happens to be the one used in revokefs/main.c.
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2121039
This adds new FlatpakTransaction API, and a new top level CLI command to
preinstall flatpaks, that is to install flatpaks that are considered
part of the operating system.
A new drop-in directory /etc/flatpak/preinstall.d/ allows configuring
what apps should be preinstalled, and a new flatpak preinstall command
installs and removes apps based on the current configuration.
A drop-in loupe.preinstall file can look something like this:
[Flatpak Preinstall org.gnome.Loupe]
Branch=stable
IsRuntime=false
The corresponding API is flatpak_transaction_add_sync_preinstalled()
which can be implemented by GUI clients to drive the actual installs
on system startup.
Resolves: https://github.com/flatpak/flatpak/issues/5579
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
We want to use collection IDs to specify what remote to install from
when processing /etc/flatpak/preinstall.d; in order for this to work
for OCI remotes, we need to permit collection IDs.
- In flatpakrepo files, don't require a GPGKey for a OCI remote
with a collection - we don't have signature verification for GPG remotes.
- Don't validate that the collection ID appears in the summary -
the image index doesn't currently contain an image ID
Instead of passing the delta URL along with the image source, when
we create an image source for a remote registry, if we find a delta
URL in the metadata, set it on the FlatpakImageSource for later use.
Centralize duplicated code for creating an image source for a remote
repository based on a summary lookup into one place.
Add support for `oci-archive:` image sources by temporarily
unpacking the archive using libarchive.
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
Similar to bundle installs, add:
flatpak install [--image] docker://registry.example.com/image:latest
flatpak install [--image] oci:/path/to/image
These is useful for testing purposes and in certain cases when installing
Flatpaks on disconnected systems.
Which allows one to create an image source from a container location.
It also adds a new FlatpakDockerReference to access different parts of a
docker reference and changes to FlatpakOciIndex to get a manifest for a
specific architecture.
This will become useful in the next commit when we're going to add
support for installing OCI images.
