This version has an important fix to the pull code that ensures
that all outstanding operations are settled before returning.
This is particularily important for flatpak that can do multiple
flatpak operations in different threads.
Closes: #1092
Approved by: alexlarsson
Followup to the previous commit to use `O_TMPFILE`, for
the cases here what we really want is to use sealed memfds. This
ensures the container can't mutate the data we pass.
Now, the args fd I was looking at turned out to be a bwrap bug,
but this is a good example of the mitigation:
```
$ flatpak run --command="/bin/sh" org.test.Hello
ls -al /proc/$$/fd
total 0
dr-x------. 2 1000 1000 0 Oct 1 16:43 .
dr-xr-xr-x. 9 1000 1000 0 Oct 1 16:43 ..
lrwx------. 1 1000 1000 64 Oct 1 16:43 0 -> /dev/pts/2
lrwx------. 1 1000 1000 64 Oct 1 16:43 1 -> /dev/pts/2
lrwx------. 1 1000 1000 64 Oct 1 16:43 2 -> /dev/pts/2
lrwx------. 1 1000 1000 64 Oct 1 16:43 255 -> /dev/pts/2
lrwx------. 1 1000 1000 64 Oct 1 16:43 9 -> /memfd:bwrap-args (deleted)
org.test.Hello$ echo foo > /proc/self/fd/9
sh: /proc/self/fd/9: Operation not permitted
```
Closes: #1064
Approved by: alexlarsson
We should not check if a persistence target exists outside of the
chroot, since its existance is irrelevant.
Fixes#1088Closes: #1089
Approved by: alexlarsson
* build-finish: Add --extension-priority option
This lets you set the priority of the extension.
* fixup! build-finish: Add --extension-priority option
* fixup! build-finish: Add --extension-priority option
There's an oustanding bubblewrap PR where we'd like to change how
we set up the rootfs; a side effect of this will be that /newroot
disappears from the `/proc` links:
[bubblewrap pull 172](https://github.com/projectatomic/bubblewrap/pull/172).
I took a stab here at adapting the code to work in both the old and new cases.
Just compile tested at the moment. There's a lot of subtleties in this code; in
particular how we end up mutating-in-place the path buffer and how that
interacts with inspecting it.
Closes: #1063
Approved by: alexlarsson
In general libglnx has expanded a lot to have a good set of low-level wrappers
for things like writing a buffer to a fd. Also, we should use `O_TMPFILE`
if available - I think the code reduction speaks for itself here.
Writing this patch as a result of looking at what fds flatpak injects.
However, *really* we want to use sealed memfds. I'll likely copy the
systemd wrappers for that into libglnx too.
Also, it took me a while to figure out the reason the `--args` code
worked before was because we were leaking the fd.
(Updated by Alexander Larsson <alexl@redhat.com> to use O_TMPFILE
in more places, like for the seccomp code, and rebased on
some preparatory cleanups)
Closes: #1060
Approved by: alexlarsson
If an extension is already installed as an unmainted extension, prefer
it instead of downloading from the remote.
Closes: #1081
Approved by: alexlarsson
We got the lstat return value check inverted, so we always regenerated
unless there was no ld.so.conf in the runtime, and then it depended
on some random memory.
Closes: #1080
Approved by: alexlarsson
This showed up when running the tests in valgrind, where
ioctl (STDOUT_FILENO, TIOCGWINSZ) fails. We fall back to 80 chars
in this case.
Closes: #1079
Approved by: cgwalters
If an extension has a higher priority than another, but is still
mounted beneath another, then the order of binds need to be different
than the ld order.
For example, in steam we want the 32bit GL extension to override any
GL in the Compat32 extension, but the GL extension needs to be be in
/usr/lib/32bit/lib/GL, whereas the Compat32 extension is in
/usr/lib/32bit.
We handle this by first bind mounting all extensions in place, in
alphabetical path order (i.e. shorter first), and then apply the
ld paths in priority order.
This matches whats described in https://github.com/flatpak/flatpak/issues/1075Closes: #1076
Approved by: alexlarsson
We prepend the app extensions, so they are before /app/lib, but
we append the runtime extensions so they are after /app/lib.
This matches what is described in https://github.com/flatpak/flatpak/issues/1075Closes: #1076
Approved by: alexlarsson
We include the app extension ld.so.conf files before the app
and after that the runtime extension conf files.
This matches what is described in https://github.com/flatpak/flatpak/issues/1075Closes: #1076
Approved by: alexlarsson
We were creating names for all extensions, even those that did
not get a ld.so.conf file created, so the count in was weirdly
inconsistent.
Closes: #1076
Approved by: alexlarsson
We strip PYTHONPATH, PERLLIB, PERL5LIB and XCURSOR_PATH from the
environment in the sandbox, because these kind of path variables
can badly affect the sandbox (e.g. pulling in host-side code).
Closes: #1078
Approved by: alexlarsson
When building the ostree-metadata branch (which only happens when
configured with --enable-p2p), we are supposed to create empty commits
which contain only metadata. However, the code to do this was wrong, and
was instead pulling in all the files from the current working directory
and committing them.
Fix that code to actually create an empty commit.
This could have been a fairly serious bug were it not for the fact that
nobody’s using this code because it’s all experimental.
Spotted as part of https://github.com/ostreedev/ostree/pull/1158.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1066
Approved by: alexlarsson
It's easy to end up with multiple flatpak installations on a system, and
it's not always clear which one(s) flatpak is using. So this commit adds
some debug output in some cases when flatpak opens an installation
directory such as /var/lib/flatpak. This is especially important for
people who build flatpak themselves because if you omit --prefix=/usr
or use --with-system-install-dir your flatpak will look in non-standard
locations like /usr/local/var/lib/flatpak.
If we were to print this every time a flatpak directory is opened, it
would flood the log. So instead add a utility function and use it
strategically. Many flatpak commands will log the directory when they
use flatpak_option_context_parse(), others in
flatpak_find_deploy_for_ref(), and for others the logging has been
added manually.
Closes: #1067
Approved by: alexlarsson
Instead of setting LD_LIBRARY_PATH to make the app load the right
libraries we run ldconfig to generate a ld.so.cache that we feed
to the sandbox as /etc/ld.so.cache. The cache itself is generated
by running ldconfig at run time, but for apps we cache the
result in $HOME/.var/app/$APPID/.ld.so/cache based on the
current app/runtime/extensions commit ids.
We also unset LD_LIBRARY_PATH, to ensure any host-side value
does not mess with the sandbox.
The default ld.so.conf we set (if the runtime has none, or an empty
one) is:
include /run/flatpak/ld.so.conf.d/*.conf
include /app/etc/ld.so.conf
/app/lib
Additionally all the extension points that have add_ld_path set gets a
ld.so.conf snippet in /run/flatpak/ld.so.conf.d.
This allows applications and extensions to install their own paths if
needed, and if the runtime wants more location they can install a
custom ld.so.conf that includes the above.
In the flatpak build case we still use LD_LIBRARY_PATH like before,
because there is no good key (like the commit ids) for keeping the
cache up-to-date. Also, the behaviour is different when building an
app for instance. If /app/lib is not in LD_LIBRARY_PATH then the
sandbox-wide /etc/ld.so.cache must be updated for a newly installed
library to work, but the sandbox is not allowed to update
/etc/ld.so.cache.
This code was originally written by Valentin David <valentin.david@gmail.com>
with changes by Alexander Larsson <alexl@redhat.com>.
Closes: #1073
Approved by: alexlarsson
This is the code needed to set up the symlinks into the runtime
to make stuff work. We will need this separately for minimal runtime
use.
Closes: #1073
Approved by: alexlarsson
This creates a symlink pointing to a target, but if the symlink
already exists, it ensures (atomically) that the previous target
is deleted. This is useful to keep a single-item cache around.
Closes: #1073
Approved by: alexlarsson
This is a method to explicitly prune the local repo, which
users might want to use if they had explicitly removed refs from
the underlying flatpak repo and want to ensure that the objects
referred to by those refs are cleared to save on disk space.
Closes: #1034
Approved by: alexlarsson
We might want to prune the repo from within the library or
the command line and may not be in a privileged context, so
we'll need to jump through the system helper to prune the refs.
Closes: #1034
Approved by: alexlarsson
It might be more efficient to perform this operation at the end of
removing a batch of refs, so perform it there instead.
Closes: #1034
Approved by: alexlarsson
In some cases, we want to include the repo part of the refspec,
for instance, if we are to pass refs directly to flatpak_dir_remove_ref
Closes: #1034
Approved by: alexlarsson
In some cases, a user might pull a ref into the local repository and
not deploy it by using FLATPAK_INSTALL_FLAGS_NO_DEPLOY. Later on, that
user might decide that they don't want to deploy the ref after all,
but there was no way to remove that ref from the local repository
in the public API, so it takes up disk space.
Add flatpak_installation_remove_local_ref_sync to remove a given
ref from the local repository if the ref is known and
flatpak_installation_cleanup_local_refs_sync to remove all undeployed
refs.
Fixes#1031Closes: #1034
Approved by: alexlarsson
