Fixes#2489
Adds and wires up a `reinstall` option to
`flatpak_dir_install_bundle`. Previously, bundle install
transactions would silently drop the reinstall flag.
(backported from commit 919d2922bf)
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
(cherry picked from commit 3773617f30)
If an SDK is already installed in a dir that is not targeted with a
flatpak transaction, and the transaction has auto_install_sdk set,
add_new_dep_op returns NULL in dep_op which is not correctly handled in
add_deps.
Fixes#5894
(cherry picked from commit c4af112df4)
Without doing so, flatpak_dir_get_config() won't reflect changes made
with flatpak_dir_set_config().
This fixes passing multiple patterns to `flatpak mask` for the system
installation.
Closes#5464
(cherry picked from commit a7ac4206c6)
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;
```
(cherry picked from commit cd0212aa40)
The current documentation is misleading, and confused multiple
experienced developers for the past two years.
Fixes#5501
(cherry picked from commit 0152272d6c)
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
(cherry picked from commit 7399dea960)
flatpak run writes /run/host/font-dirs.xml, but flatpak build so far
didn't. This resulted in fontconfig writing:
Fontconfig error: Cannot load config file "/run/host/font-dirs.xml": No such file: /run/host/font-dirs.xml
to the stderr of all processes utilizing fontconfig and run during
flatpak build, as /run/host/font-dirs.xml is included via
/etc/fonts/50-flatpak.conf. This could cause issues for tests run during
building an application, for example.
Closes#6137
(cherry picked from commit 054f4f4a7b)
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.
We already build and test with asan with the newer
toolchain in the ubuntu 24.04 job. Sometimes the older
toolchain found in 22.04 or the asan version will
trigger issues that are either false positive or that
have been already against in newer versions.
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
Most access to the `client_pid_data_hash` hash table are unsafe due to
threading.
One approach to solve this would be to protect the hash table with a
mutex, but as per a deeper analysis, nothing in these callbacks is
slow or heavy enough to justify the need for separate threads.
Make method invocations run in the main thread.
Closes: https://github.com/flatpak/flatpak/issues/5605
