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>
Due to previous bugs we were leaving a lot of temp files around
in the appstream deploy dirs, which could add up to using a lot of
space. So, lets find and delete these on updates.
This check only happens on a successful update to a new appstream,
which isn't that often, so the cost of this check is unlikely to be a
problem.
If during appstream deploy there is an error, the temporary files were
not deleted, resulting in leaked files in /var/lib/flatpak/appstream.
Over time these could add up to a significant size. In particular this
happes if several deploys happen in parallel, because then the final
move into place will fail with EEXIST.
This fixes the cleanup of both the temporary directory and the temporary
link on any error.
Fixes https://github.com/flatpak/flatpak/issues/4735
Put the configured server address string in PULSE_SERVER if it appears
to be remote. This should be enough for apps that already have network
access via --share=network.
If remote access to a PulseAudio server has been selected but the app
does not already have the --share=network permission, we don't want to
add --share=network automatically, because that would open up the app's
access to network resources, perhaps unexpectedly. However, users of
this non-default configuration can use `flatpak run --share=network` or
`flatpak override --share=network` to open up that access if they
consider it to be safe enough.
Resolves: https://github.com/flatpak/flatpak/issues/3908
Signed-off-by: Simon McVittie <smcv@collabora.com>
As with non-path-based AF_UNIX sockets, both of these are going to
require --share=network to be enabled, so print a warning if it isn't.
We don't automatically enable --share=network, because that elevates
the privileges of apps that would otherwise have entered a new network
namespace, but regular users of remote X11 can choose to enable it with
`flatpak run --share=network` or `flatpak override --share=network`.
Resolves: https://github.com/flatpak/flatpak/issues/397
Signed-off-by: Simon McVittie <smcv@collabora.com>
If the filesystem-backed Unix socket (G_UNIX_SOCKET_ADDRESS_PATH) does
not exist, X11 clients can also use a Linux abstract Unix socket
(G_UNIX_SOCKET_ADDRESS_ABSTRACT), or even a TCP socket.
Both of these are going to require --share=network to be enabled, so
print a warning if it isn't. We don't automatically enable
--share=network, because that elevates the privileges of apps that would
otherwise have entered a new network namespace, but users can make it
work with `flatpak run --share=network` or
`flatpak override --share=network`.
When falling back to an abstract Unix socket or to a TCP socket, we
can't remap the display number to the fixed :99.0 that we normally use,
so adjust write_xauth() to be able to avoid doing that.
Resolves: https://github.com/flatpak/flatpak/issues/4702
Signed-off-by: Simon McVittie <smcv@collabora.com>
In practice, au_len comes from one of the length fields in an Xauth
struct, which are all of type unsigned short, so it cannot really be
negative; but if we passed a negative argument here, the comparisons
would not behave as intended. Use the more correct size_t.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We're not going to call XauDisposeAuth on local_xa, so it's OK to put
a "borrowed" constant string here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
