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 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
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.
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>
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.
To avoid passing around combinations of a FlaptakOciRegistry with
repository and digest, add a FlatpakImageSource type.
This also reduces duplicated code where every place that did
this independently retrieved the repository and image config.
Docker and podman can be configured to use mutual TLS authentication
to the registry by dropping files into system-wide and user
directories. Implement this in a largely compatible way.
(Because of the limitations of our underlying libraries, we
can't support multiple certificates within the same host config,
but I don't expect anybody actually needs that.)
The certs.d handling is extended so that certificates are separately
looked up when downloading the look-aside index. This is mostly
to simplify our tests, so we can use one web server for both -
in actual operation, we expect the indexes to be unauthenticated.
Also for testing purposes, FLATPAK_CONTAINER_CERTS_D is supported
to override the standard search path.
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
The systemd Desktop Environments conventions for cgroup names is
app[-<launcher>]-<ApplicationID>-<RANDOM>.scope
where RANDOM should ensure that multiple instances of the application
can be launched. Currently flatpak uses the PID of itself but the
instance fullfills this convention and is a bit more useful for matching
the cgroup to a flatpak instance.
There are cases where flatpak is doing some internal work (apply extra
data) where there is no instance id, and more philosophically also no
app instance. In those cases we simply do not move the process to the
cgroup with the XDG convention.
The original idea behind this code was that the initial lockless scan
of reachable objects will make the locking one fast enough that
it won't matter to software managing flatpak repos like flat-manager.
Few years later I can say this is not true, and the locking variant
of scan does take too long and affects Flathub's publishing process.
By keeping only the lockless variant in dry run, we can run it on a
weekly schedule without affecting operations, and issue actual pruning
with flat-manager which will hold a lock in external system and avoid
executing any actions requiring locking to avoid errors/timeouts.
Currently, app installs and updates are treated the same from the point
of view of the parental controls permissions checks. This was intended so
that parents have to re-check each app update to make sure it’s still
appropriate for their children.
In practice, though, parents are not that hands-on, and there are a lot of
regular app updates. The tradeoff between app updates (which bring
security fixes and features) and not changing so much in apps that a
parent’s initial assessment of their suitability for their child is
probably skewed the wrong way. We should be preferring updates (in
particular, so we get security updates), and assuming that if an app is
OK to begin with, it’s probably not going to change so radically as to
become unsuitable for a child with an update.
As a data point, Google Play’s parental controls will allow apps to be
automatically updated even if a child account can’t install new apps.
So, implement this by splitting the existing
`org.freedesktop.Flatpak.override-parental-controls` polkit action in
two: the existing action for _installs_, and a new
`org.freedesktop.Flatpak.override-parental-controls-update` action for
_updates_. `FlatpakDir` is changed to use the appropriate action
depending on whether an app is being installed from scratch or updated.
The default policies for the two actions differ.
Users/Distros who disagree with the new default policy can provide their
own polkit rules to change the behaviour of
`override-parental-controls-update` so that it matches
`override-parental-controls`, to bring back the old behaviour.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: https://github.com/flatpak/flatpak/issues/5552
udmabuf allows clients to allocate virtual memory as dmabufs,
which then potentially can be imported by other dma subsystems -
most importantly GPU drivers and KMS. This can avoid copies and
thus increase performance.
Unlike other dmabuf allocators like e.g. dma heaps this doesn't
have known issues relevant for sandboxing. Notably memory accounting
works as expected, so apps can't use udmabuf to escape resource
limitations. For this reason systemd, since version 257[1], grants
"uaccess" access to udmabuf by default, considering it as "safe".
With udmabuf increasingly being availably by default, various apps
and libraries start making use of it - examples include libcamera,
mesa llvmpipe and Gstreamer. Thus let's grant access to it in Flatpak
as well.
For now limit it to "dri" access as sharing buffers with GPUs is
the most common use-case. There is no strong reason to not lift
restrictions further if the need arises, though.
1: https://github.com/systemd/systemd/pull/33738
Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Robert Mader <robert.mader@collabora.com>
In the real at-spi2-core client library, AT_SPI_BUS_ADDRESS is treated
as higher-precedence than the AT_SPI_BUS X11 atom or the GetAddress()
D-Bus method. Mimic this.
We don't currently implement querying the X11 atom because that would
require a libX11 dependency, so leave a comment indicating where it
would appear in precedence order.
Signed-off-by: Simon McVittie <smcv@collabora.com>
To handle those details at the right place (flatpak-run-wayland.c), we
pass if the wayland socket is allowed to flatpak_run_add_wayland_args
and handle it there instead of in the caller.
Closes#3948
Static libraries do not carry information about their dependencies.
Thus, libflatpak_dep must include all of the dependencies for
libraries to link against libflatpak. To do this, I've repurposed the
libflatpak_common_deps variable, which previously was either empty or
contained only wayland_client, and was then included into the list of
dependencies for libflatpak-common, to be a list of all dependencies
required to both build libflatpak-common, and link against it (or
libflatpak).
This fixes building Flatpak with -Ddefault_library=static. gtkdoc
must currently be disabled due to a Meson bug I'm working on[1].
[1]: https://github.com/mesonbuild/meson/pull/14257
The ostree and Flatpak APIs both refer to "end of life", but
this internal #define (though not the data stored in the cache)
refer to "end of line".
Fix this.
This is a new warning. Reproducible on F41
Fixes:
../common/flatpak-installation.c:1963: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:1858: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:2129: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:2014: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:1732: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:2177: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:2220: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:2608: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
Signed-off-by: Hubert Figuière <hub@figuiere.net>
Instead of hardcoding /var/tmp when temporarily downloading layer
tarballs, support overriding with a FLATPAK_DOWNLOAD_TMPDIR
environment variable.
We don't use TMPDIR because the layer tarballs can be very big
(in extreme cases like an SDK > 1GB), and TMPDIR is more
likely to point to a in-memory tmpfs.
