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
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
The kernel used on some autobuilders for the Debian PA-RISC port
can do "bwrap --ro-bind / / /bin/true", but not the bwrap invocations
made during the actual testing, which fail with "Creating new namespace
failed: Invalid argument". Make the trial bwrap invocation more like
what Flatpak actually does, so that these tests will hopefully be
skipped on such kernels.
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876743
Signed-off-by: Simon McVittie <smcv@debian.org>
