The subpath is resolved relative to the root of the commit, so we can
use either an absolute or a relative path interchangeably. When using
libostree < 2021.6 with GLib >= 2.71, absolute paths cause an assertion
failure here; that was a libostree bug and was fixed in 2021.6, but we
can interoperate with more versions by sticking to relative paths, and
there's no real reason to prefer absolute.
Resolves: https://github.com/flatpak/flatpak/issues/4805
Co-authored-by: Corentin Noël <corentin.noel@collabora.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is specifically for running build-time tests in the Autotools build
system, and is not used when running installed-tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
* Add `--add-seccomp` (prerequisite for flatpak/flatpak#4462)
* Add a warning when repeated options are ignored
* Add a Meson build system
* Invoke bash via `PATH`
* Exit early when `argc == 0`
Signed-off-by: Simon McVittie <smcv@collabora.com>
* Improve compatibility with eCryptFS (related to #4673)
* Improve compatibility with copying pseudo-files from /proc
* Add a flag to skip fchown() in glnx_file_copy_at()
* Add a rewinddir() wrapper to GLnxDirFdIterator
* Rename its generated config header to libglnx-config.h
* Fix a potential double-free while manipulating xattrs
* Use REUSE for copyright/licensing statements
Note that after merging this in an existing checkout, it will be
necessary to re-run autogen.sh.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If the user hasn't typed a '-', don't offer options in the tab
autocompletion. This is consistent with other linux commands, and less
messy.
Fixes https://github.com/flatpak/flatpak/issues/4753
In some OS configurations, unprivileged users cannot read back messages
that they have written to the system log. This test cannot succeed if that
happens, so skip it.
In particular, if the Journal is only in-memory rather than persisted
to disk (as it was by default in Debian 10), then there are no per-user
Journal files, only a single system-wide Journal which requires privileges
to read.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Fixes: 8b05f6b3 "Add a unit test for the history command"
All the details of the bug are in:
https://github.com/ostreedev/ostree/pull/2549https://github.com/flatpak/flatpak/issues/3479
This patch works around it by marking the commit we're about to pull
partial, so that if the .commit object exists in a staging directory
from a previous failed pull, it will not be erroneously considered a
complete commit, even by affected versions of libostree that don't have
the above patch. If for some reason the commit in the staging dir is
complete, libostree should harmlessly verify that and pull it in.
Usually the commit we are pulling does not already exist in the local
repo, but add a check anyway so we don't risk marking a complete commit
as partial, and so this works on the code path from
"flatpak install --reinstall ..."
Fixes#3479
Just as we already call flatpak_disable_fancy_output() in
flatpak_option_context_parse() in case verbose output is enabled via CLI
options, disable fancy output in case verbose output was enabled via the
G_MESSAGES_DEBUG env var. Without this change, the result of doing e.g.
$ G_MESSAGES_DEBUG=OSTree flatpak install ...
is pretty useless and ugly, when the output isn't being redirected to a
file, since the debug messages are overwritten when we redraw to show
progress updates.
This makes the output of "flatpak list" a bit ugly when G_MESSAGES_DEBUG
is set, but it seems like a small price to pay.
In https://github.com/flatpak/flatpak/issues/4535 it was brough to light
that the search command strips the ".desktop" suffix from app IDs even
if they genuinely end in .desktop. This commit fixes the reverse issue
now that we've ported to libappstream: don't include the .desktop suffix
even if it's present in the id of the appstream component, which it
sometimes is.
Fortunately we already ignore any components that don't have flatpak
<bundle> elements, so we can unambiguously get the ID there.
Fixes#4535
Older versions of libappstream don't provide AS_CHECK_VERSION() so we
can't use that, and we need the check because as_component_get_branch()
is only in libappstream >= 0.14.0, and the return value of
as_metadata_parse_file() changed in 0.14.0
Since the port from libappstream-glib to libappstream, these wrappers
are trivially thin and can be dropped.
This commit introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
libappstream-glib is mostly unmaintained, and libappstream is more
actively developed (and up to date with the AppStream specification).
Port from libappstream-glib to libappstream. Handily, a lot of the APIs
are exactly the same. The main changes are:
* `AsApp` → `AsComponent`
* `AsStore` → `AsMetadata`
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(Mostly done by Philip, then Phaedrus finished this)
It is common for the build directory to be within a Git checkout.
Developers never want to check this directory into Git.
Make 'flatpak build-init', and hence 'flatpak-builder', create a blanket
.gitignore file inside this directory, so the containing checkout
doesn't need to predict the name of the build directory and ignore it.
(Inspired by Meson's treatment of its build directory.)
Older versions of bubblewrap would create a --file with mode 0666
(world-writeable), which is unexpected. Since bubblewrap 0.5.0, the
default is still 0666 for backwards-compatibility, but we can change it
with the new --perms argument. Switch to mode 0600 (private to user)
which is consistent with the mode of the --ro-bind-data version of
that file.
This is not a security issue: from outside the sandbox, this file can
only be accessed via /proc/$pid/root, which the kernel restricts to be
accessed by processes that could trace the sandboxed process (the same
uid or a privileged process), leading to a practical effect similar to
0600 permissions. Inside the sandbox, all processes have the same uid,
so 0600 and 0666 permissions are equivalent.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In older versions of bubblewrap, the --dir argument could only create
directories with mode 0755 (world-readable). The default mode is
still 0755, but since bubblewrap 0.5.0, we can change this to the mode
recommended by the basedirs spec (0700, private to user).
Since version 1.11.1, the --dir used here is normally redundant, because
each app-ID gets its own XDG_RUNTIME_DIR imported from the host
(it's actually $XDG_RUNTIME_DIR/.flatpak/$FLATPAK_ID/xdg-run on the host)
and those are correctly created with mode 0700. The one case where this
change makes a difference is that a sub-sandbox, created by
flatpak-spawn --sandbox or equivalent, does not share the common
XDG_RUNTIME_DIR and instead received an XDG_RUNTIME_DIR private to that
instance, with its permissions coming from this --dir argument.
This is not a security issue, because processes outside the sandbox can
only access this directory via /proc/$pid/root, which is only accessible
by processes that would be allowed to trace the sandboxed process
(either the same uid or a privileged process), resulting in behaviour
similar to the canonical 0700 mode. Inside the sandbox, all processes
have the same uid, so 0700, 0755 and even 0777 permissions would be
essentially equivalent.
However, some libraries that interact with XDG_RUNTIME_DIR, most notably
Qt, verify that its mode is 0700 as a hardening mechanism, and these
libraries did not work inside a Flatpak sandbox without being patched
to be more permissive.
Resolves: https://github.com/flatpak/flatpak/issues/3397
Signed-off-by: Simon McVittie <smcv@collabora.com>
- Copy 1.12.5 entry from the flatpak-1.12.x branch, remove changes
that were in that release from the 1.13.1 entry
- Fix typos
- Add issue/PR numbers
- Mention #4111 being fixed
It is already the case that when we are using ALL_DIRS, we always
combine it with OPTIONAL_REPO, meaning no need to populate empty
installations. ALL_DIRS is used for commands that iterate through all
known installations to enumerate apps/runtimes, such as `flatpak run`
and `flatpak list`; for these commands, it's reasonable to say that
if the installation does not have a libostree repository, then that's
equivalent to it having a libostree repository with no apps and no
runtimes. Make this happen automatically if forgotten.
For STANDARD_DIRS, we were inconsistent about this: `flatpak remote-list`
had OPTIONAL_REPO, but the other commands did not.
STANDARD_DIRS is used for `flatpak create-usb`, and for all the commands
that manipulate remotes.
For the commands that manipulate remotes, it seems reasonable to say
that if an installation has no libostree repository and we are unable
to create one, then that's equivalent to an installation with a
libostree repository but no remotes.
Similarly, for create-usb, an installation where we are unable to create
a libostree repository seems like it should be equivalent to an
installation whose libostree repository does not contain any of the
refs we are interested in.
Resolves: https://github.com/flatpak/flatpak/issues/4111
Signed-off-by: Simon McVittie <smcv@collabora.com>
libostree makes heavy use of fd-based I/O, which has the disadvantage
that it is rarely obvious what path an error message is referring to.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we are running a CLI command in the background, then EnsureRepo
might require authorization. Silently skip it if allow_empty was true,
as it is for commands that iterate through all repositories.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously, if /var/lib/flatpak didn't exist then we would use the
system helper to create and populate it, but if it existed and was empty,
we could only populate it if we had privileges. This led to errors from
libostree:
Creating repo: mkdirat: Permission denied
The EnsureRepo method call is allowed by default for active local users,
so do this even if allow_empty is true: this will incorporate
/etc/flatpak/remotes.d into the repository, whether it is newly-created
or not. This makes a `flatpak search` work immediately, without having
to fetch metadata explicitly.
Signed-off-by: Simon McVittie <smcv@collabora.com>
