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
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
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
A few fixes worth having, also just testing Homu.
```
Colin Walters (2):
fdio: Open target dirname for glnx_file_copy_at()
lockfile: Use an `initialized` member rather than explicit init
Jonathan Lebon (1):
macros: use size_t for glnx_strjoina len
Philip Withnall (1):
shutil: Fix assertion failure in glnx_shutil_mkdir_p_at()
```
Closes: #1046
Approved by: alexlarsson
We used to only expose symlinks if the path to one was explicitly exposed,
like --filesystem=/symlink, but if you did say --filesystem=/symlink/dir, then
we would make /symlink be a regular directory in the sandbox tmpfs.
This means all exports are fully resolved, which allows use to remove the
workaround for symlinks that we had with sorting by "level".
We also add a FAKE_MODE_DIR, which is used to ensure the homedir is there,
created on tmpfs if needed only, while handling symlinks correctly.
This means that flatpak works well even if $HOME is on a symlink.
If the target of a direct bind, such as $home/.var/app/$appid/ is
a symlink, and the symlink contains absolute pathnames, then they
will not resolve correctly in the bwrap setup code due to the
fact that the final root is on /newroot, not /, so we resolve
the target paths before we call bwrap.
When we're resolving a symlink to see if the destination is visible, then
we have to actually append the rest of the path to look at the final
target, not just the intermediate symlinked directory.
When we hide a directory like that and it is a symlink we need
to hide the symlink target. Additionally, when we're checking
whether we need to mount the tmpfs we need to check that the
target is an actual dir, rather than a symlink to a dir.
Fixes https://github.com/flatpak/flatpak/issues/1032
This is taken in exclusive mode whenever we prune the repo. Anything
that is not protected against object disappearing from the repo can
take the lock in a shared mode to avoid running at the same
time as a prune operation.
The two operations the are problematic in this respect is
Pull:
* During the pull we see that some object we require is already available
and doesn't need downloading. We can't have it be removed before we
commit the transaction.
* During the transaction commit we're moving the object to the
repo, and they risk being pruned as unreachable until we have updated
the ref.
Deploy:
* Once we start checking out a particular ref we assume all the object
from it is reachable. If the ref is updated in parallel some object
can become unreachable and removed.
So, we take shared locks in these operations.
In the prune operation we take the block non-blocking, and skip
the prune entirely if some other operation is outstanding, because
we don't want to block a long time, and its likely that due to the other
operation we will run prune shortly anyway.
Note: Nothing protects the system-helper case when we download to a separate
repo. However, if there is a race we will get an error when importing this
to the system repo, so we'll never end up in an inconsistent state.
Previously we would still try to look up the remote information
to get the correct ref, this might not be supported in a case where
the user does not have an internet connection at the time that
applications are to be installed from the local repository.
