When installing a flatpak with extra-data we execute the apply_extra
script from the flatpak to extract the extra data files we
created. This script runs with very little filesystem acces, but it
does have write permissions to the location that will eventually be
/app/extra in the finished flatpak. This is especially problematic for
the systemwide install case, because the script is then run as root,
so it could potentially create a setuid file there.
Such a file would not be usable inside the sandbox (because setuid is
disabled in the sandbox), but it could potentially be a problem if the
user could be tricked into running the file directly on the host. This
is the same behaviour as e.g. rpm or deb which both can install setuid
files, but we want to guarantee that flatpak is better than that.
The fix is to run the script with all capabilities dropped (bwrap
--cap-drop ALL) which removes a bunch of possible attack vectors (for
instance setting file capabilities). However, even without
capabilities, it is possible for a user to make any file setuid to the
same user, so we also need to canonicalize the permissions of all
files generated by running the script.
Additionally, while running the script we set the toplevel directory
only be accessible to the user, meaning we will not temporarily leak
any potential setuid files to other users.
Note, this commit actually goes furthen than that and completely
canonicalizes all the file permissions to be the same as those
otherwise used by flatpak. For example we fix up cases where the
script creates files writable or unreadable by non-root users.
Closes: #2323
Approved by: alexlarsson
If you have a pre-existing remote configured its exact definition
might differ from the one specified in a flatpakrepo file and yet
be the same.
For example, i have:
$ flatpak --user remotes -d
Name Title URL Collection ID Priority Options
flathub Flathub https://dl.flathub.org/repo/ org.flathub.Stable 1
Yet when i install a flatpakref:
$ flatpak --user install http://flathub.org/repo/appstream/org.gnome.gedit.flatpakref
The application org.gnome.gedit depends on runtimes from:
https://dl.flathub.org/repo/
Configure this as new remote 'flathub-1' [y/n]:
Because the flathub flatpakrepo does not yet have the collection id specified.
So, we need to be more lenient when matching the pre-configured remotes.
Closes: #2324
Approved by: alexlarsson
This commit adds a key called DeployCollectionID to the flatpakref and
flatpakrepo file formats, which is intended to replace the CollectionID
key (which is still supported but deprecated). The reason for the change
is the same as for the metadata key change from xa.collection-id to
ostree.deploy-collection-id, which is that old versions of Flatpak
(roughly 0.9.8 through 1.0.1 depending on compile time options) hit
various bugs when collection IDs are in use. Flathub will soon enable
the metadata key to deploy collection IDs, and this change means Flathub
can also deploy the collection ID in flatpakref and flatpakrepo files
without affecting old clients.
Adding DeployCollectionID to the flatpakref and flatpakrepo files will
mean the flathub remote can be automatically configured with a
collection ID without depending on the metadata key to do that.
Closes: #2329
Approved by: alexlarsson
We want to avoid unnecessary confusion and complications,
so we rule out IDs that are problematic because they will
clash with the default installations.
At the same time, make the error messages for parsing
custom installations more informative.
This is currently only used in the ‘search’ built-in command, but will
need to be used in upcoming parental controls filtering changes in
Endless OS (which will go upstream eventually) too.
This introduces no functional changes.
The CFLAGS/LIBADD changes are necessary because of the new
AppStream #includes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #2296
Approved by: matthiasclasen
We generate various configuration files for each sandbox instance,
and expose them to the sandbox using flatpak_bwrap_add_args_data,
which in the end passed --bind-data to bwrap. These files are not
sensitive or shared, but it still doesn't really make sense for
the sandbox to allow them to be modified, so lets switch them
to --ro-bind-data.
This affects these files in the sandbox:
$HOME/.var/app/$APPID/config/user-dirs.dirs
/etc/group
/etc/ld.so.conf
/etc/passwd
/etc/pkcs11/modules/p11-kit-trust.module
/etc/pkcs11/pkcs11.conf
/etc/timezone
/run/flatpak/ld.so.conf.d/*.conf
/run/user/$UID/pulse/config
/run/user/$UID/Xauthority
We mistakenly bind-mounted the runtime /usr/etc files read-write in
/etc, which means that application could modify some parts of the
runtimes (at least when using a per-user installed runtime). Fix
this by using a --ro-bind.
The error messages here make it appear that values can
be prepended with a '!', but a few lines down we throw
an error if thats the case.
Closes: #2298
Approved by: matthiasclasen
A convenience wrapper around ostree_repo_get_min_free_space_bytes().
Clients programs like gnome-software can get the value of minimum free
space as defined in the OSTree repo. This can be useful in various
disk-space checks these client program can implement.
At Endless, we have downstream heuristics in gnome-software which
determine the success/failure likelihood of an install/update
operation to some extend. Depending upon the likelihood of the
success/failure we dispatch install/update/auto-update operations.
With client programs gaining features such as auto-updates, it makes
sense to have a min-free-space API so that these programs can check
free-space availablity vs minimum free space defined by user inside
OSTree's repo before auto-updating. Although, OSTree will certainly
fail operations over-stepping min-free-space's value; It's just a
matter of convenience to provide a way to query the value to client
programs as well.
Closes: #2274
Approved by: matthiasclasen
This commit implements a feature in the multiple choice prompt that
mirrors the behavior in the yes/no prompt where it can default to "yes"
when the user only presses Enter. In the case of the multiple choice
prompt, it only defaults to the first choice on Enter if there's only
one option (e.g. you're asked if you want to install from the "flathub"
remote as opposed to being asked to choose between the "flathub" and
"eos-apps" remotes).
This feature can be turned off on a per-prompt basis if we want explicit
user input for something but I didn't find that necessary for any of the
existing prompts.
Also note that as with the yes/no prompt defaulting to yes on Enter,
this only applies for interactive terminals. If Flatpak is being run by
a script no choice will be made automatically.
This should save users unnecessary keystrokes, such as when they use
"flatpak install devhelp" and are asked to confirm that the Flathub
remote is the one to use (now they can just press Enter).
Closes: #2288
Approved by: matthiasclasen
Currently when the Flatpak command line prompts the user with a yes or
no question, the user must type "y" or "n" to respond. This commit
changes it so that the prompt can assume "yes" if the user just presses
Enter. In that case the prompt ends in "[Y/n]" rather than "[y/n]". If
there are some operations that are considered dangerous, we can still
require explicit user input on those, but as far as I can tell those
criteria don't apply to any existing prompts.
This behavior of allowing the user to just press Enter is consistent
with how apt works for example.
Note that this is distinct from the "--assume-yes" option we have, since
that won't prompt the user at all when a decision needs to be made.
Closes: #2113
Approved by: matthiasclasen
This commit implements a "typo helper" for the install command, so that
if you don't get the app ID exactly correct you're prompted with
similarly named apps available in the remote that you can choose from.
Essentially this allows you to do "flatpak install flathub devhelp"
instead of "flatpak install flathub org.gnome.Devhelp".
The choice is only made for you in two cases: 1. If it's an exact match
and there's only one match, it is used as before this commit. 2. If the
-y/--assume-yes option was used and there's only one match, it is used.
Presumably scripts would always specify the full app ID, so this should
only affect users on the command line who choose to use that option.
In the future we may want to use the groundwork laid in this commit to
add similar functionality to other commands, like perhaps remote-info
and run.
This is a partial fix for https://github.com/flatpak/flatpak/issues/1258Closes: #2113
Approved by: matthiasclasen
This moves the implementation of the Levenshtein "edit distance"
algorithm from app/ to common/ so it can be used in an upcoming commit.
Closes: #2113
Approved by: matthiasclasen
flatpak_dir_find_remote_refs() and flatpak_dir_find_remote_ref() have
support for finding remote refs via P2P means because
flatpak_dir_list_all_remote_refs() uses the list of refs in the xa.cache
in that case. So remove the outdated comments.
Closes: #2113
Approved by: matthiasclasen
This is a little better than just checking that the file
exists. Still does not protect against a stale socket.
Closes: #2258Closes: #2271
Approved by: matthiasclasen
OSTree now has a repo config option to set which repo finders (that is,
sources for refs) will be used, and API which exposes the default set
(which was either configured by the user or decided by libostree). So
this commit changes flatpak_installation_list_remotes_by_type() to
respect that configuration, since that's the only place flatpak passes a
set of OstreeRepoFinder instances to libostree.
See also https://github.com/ostreedev/ostree/pull/1758/Closes: #2264
Approved by: pwithnall
Neither flatpak_variant_builder_init_from_variant nor
flatpak_gvariant_new_empty_string_dict are used anywhere.
Closes: #2252
Approved by: matthiasclasen
Avoid the 3-second 'afterlife' of instances by using
kill (pid, 0) instead of checking the file lock. We
trade pid for lock races, but this seems more reliable.
Also add flatpak_installation_launch_full that returns
a FlatpakInstance for the launched app, and lets us
avoid races around killing the app, by using a child
watch.
Closes: #2221
Approved by: matthiasclasen
If we use a remote name containing questionable characters
such as newlines or '[', we will run into assertions in
GKeyFile. To avoid that, check that the group name we
pass is valid, and throw an error otherwise.
Found while writing tests.
Closes: #2244
Approved by: alexlarsson
When trying to uninstall a non-installed app, we run
into an assertion, because the code forgets to return
after setting the expected error.
Found while writing tests.
Closes: #2244
Approved by: alexlarsson
Some remote metadata can cause changes to the local configuration for a
remote, but Flatpak is not properly reloading the new config after
making changes. Specifically in flatpak_transaction_update_metadata() we
call flatpak_dir_update_remote_configuration() for each remote and then
try to reload the configuration by calling flatpak_dir_recreate_repo().
The problem is that while this reloads the config instance stored by the
repo member of the FlatpakDir, the FlatpakTransaction object still has
FlatpakRemoteState objects stored which were initialized from the old
config.
A consequence of this is that if a remote repository has the
"ostree.deploy-collection-id" key set in its metadata, the next
install/update operation from that remote will fail with the error
message "Can't pull from untrusted non-gpg verified remote", and then
subsequent operations will succeed. This is because during the first
operation Flatpak will add the collection ID to the local configuration
in flatpak_transaction_update_metadata() but then in
flatpak_dir_install() the outdated FlatpakRemoteState object will be
used which still has no collection ID.
So this commit frees all the stored FlatpakRemoteState objects on the
transaction, so they will be recreated when they're needed (based on the
new config).
Closes: #2243
Approved by: alexlarsson
Write to the systemd journal for basic operations
that modify installations, such as pull, deploy,
uninstall. Include some useful information as
separate fields, such as OPERATION, INSTALLATION,
REMOTE, REF, COMMIT.
We add the logging in the api layer that is used
by the system-helper as well, so that changes
from that side are logged as well.
All logs we write currently use the same message
ID, defined as FLATPAK_MESSAGE_ID in the headers,
for easy retrieval of messages.
If a transaction contains both an install for an app
and an uninstall for the runtime that it needs, error
out, since this is inconsistent.
Closes: #2196
In version 0.99.1 (065053775b) flatpak
stopped inheriting permissions from the runtime, because that made
the story about application permissions way to complicated. What
we want is to have a static set of permissions for the app that
is frozen at install time.
However, inheriting permissions from the runtime makes a lot of sense
as certain permissions are required from the runtime, in particular this
is used by the kde runtime to read the kdeglobals file, etc.
So, to combine the best of the two worlds, we now do inherit permissions,
but at build-time (and you can disable it if you want). This way
kde apps don't have to repeat themselves, but we still get static
application permissions.
Closes: #2230
Approved by: alexlarsson
This exposes a /etc/timezone with the current timezone, as per the old
debian spec: https://wiki.debian.org/TimeZoneChanges
In case we're using the session-helper this will be extracted from
the host config and applied whenever that changes.
Normally timezone info is specified by /etc/localtime being a symlink
into the locale data, and you can look at the symlink value itself.
However, in the sandbox we can't update a symlink in /etc at runtime,
nor can we make it of the canonical form as that would point into the
runtime. This is why /etc/timezone is used.
This fixes https://github.com/flatpak/flatpak/issues/2190Closes: #2214
Approved by: alexlarsson
Currently, if flatpak_installed_ref_get_latest_commit() returns NULL
(which means the ref doesn't exist in the local repo) we assume any
remote commit could be an update in
flatpak_installation_list_installed_refs_for_update() when a collection
ID is not configured on the remote. When a collection ID is configured,
if get_latest_commit() returns NULL it causes a crash in
ostree_repo_load_commit(). So this commit prevents the crash and makes
the behavior in the post-collection-id world consistent with the
behavior in the pre-collection-id world.
It's difficult to write a test for this that's not contrived, without
knowing what circumstances led to the disappearance of the ref from the
repo.
Fixes https://github.com/flatpak/flatpak/issues/2216Closes: #2229
Approved by: alexlarsson
There is a race; flatpak_installation_launch may return
before bubblewrap has written the bwrapinfo.json file.
Make flatpak_instance_get_child_pid() deal with this and
document that the function may return 0 for a little
while.
