If it's an opaque integer on the host system, it might as well be an
opaque integer in the container too.
Fixes: #3416
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit a36e0183b1)
It is a common user error to prepend many flatpak commands with sudo
and doing so with run is quite unsafe and can cause issues.
This check simply handles the `sudo flatpak run foo` case and does
not prevent running as root or even running in a shell created by
sudo.
See also #1357
This new permission exposes the host /dev, which is normally not visible
even with --device=all, as it is not really a device node but rather
a bunch of shared memory blocks available on the host.
This access is needed by jack, as explained at:
https://github.com/flatpak/flatpak/issues/1509
Long term I think a better solution for pro audio (like pipewire) is
a better solution, but for now we should at least allow jack apps to work.
It turns out d91660fe2a accidentally
broke the inheritance of non-stdin/out file descriptor into children
of "flatpak run" which broke the fd passing in the flatpak spawn portal.
This reverts that, allowing all fds not specifically marked as CLOEXEC
by other means to be inherited into the child.
Fortunately the regression was not in any stable release.
Given the pid of an existing flatpak process, if --parent-expose-pids is
specified, the new sandbox is run such that its processes are visible in
the specified sandbox.
In all other senses the two are disjoint though. The new sandbox is
still isolated from the host and the existing sandbox.
This means sandboxes with dbus access can use portals etc, but they can't
talk to the main app, or impersonate it, but you can still use dbus and
well-known names to talk to them if needed.
It does mean however that if you use this, different sandboxes can see each
other on the bus, so be careful.
Mount ~/.local/share/icons at /run/host/user-share/icons in
the sandbox, so runtimes can add /run/host/user-share to
their XDG_DATA_DIRS and get access to locally-installed
icon themes.
There is a kernel issue which has been fixed in linux 4.9:
e98d413703
Which makes it impossible (on older kernels) to mount devpts unless
uid 0 is mapped in the user namespace. Bubblewrap works around this
by using two namespaces, the base one which sets up everything (and
thus owns all the other namespaces), and then at the end a child of that
that remaps uid 0 to the real uid.
Unfortunately, this makes it impossible to enter the bubblewrap user
namespace, because there are no references to the intermediate
user namespace we can use. To work around this we make a bind mount
of the intermediate namespace during setup using --ro-bind-try which
we can use for nsenter.
This writes temporary files needed for .xauth and seccomp to /tmp
rather than /var/tmp. This is useful because /tmp is more likely
to be tmpfs, and thus not run into diskspace issues.
Prevent the user from running a flatpak app if that app is filtered by
the parental controls applied to the user.
If flatpak is running as a system user (UID < 1000), ignore failure to
load the app filter. This could happen if a flatpak is run in the
gnome-initial-setup session, before the user’s account is created.
Includes contributions by André Magalhães.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://github.com/flatpak/flatpak/pull/2797
As per https://gitlab.gnome.org/GNOME/glib/merge_requests/490
there is a bug in glib < 2.60 where g_spawn_* can sometimes deadlock
due to using malloc in the child func to close fds.
We work around this in places where the code is (potentially) threaded
by passing glib flags to leave fds alone and then do a very naive
(but safe) fd cloexec loop ourselves.
The org.freedesktop.Flatpak user D-Bus service isn't just used by
flatpak(1) or applications running as Flatpaks. It's also used by
toolbox(1) for similar reasons:
* To keep various configuration files inside the container
synchronized with the host
* To let the container request certain commands to be run on the host
The org.freedesktop.Flatpak D-Bus service itself doesn't need much in
the way of dependencies, but inherits a lot of unused shared library
linkages through the libflatpak-common.la convenience library. Removing
these unused shared libraries reduces the footprint of toolbox(1) for
those who care about such things. eg., Fedora CoreOS.
This commit brings down the number of shared libraries to 19 from 62.
Closes: #3052
Approved by: alexlarsson
This is in preparation for writing some unit tests
for these functions. Apparently they are not too
trivial to get them wrong.
Closes: #2880
Approved by: alexlarsson
The function was already leaking the result of
extract_unix_path_from_dbus_address() in the case where that call
succeeded. Since commit 0e545799 it would also leak the result of
g_build_filename in the case where it checked $XDG_RUNTIME_DIR/bus.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2877
Approved by: matthiasclasen
This matches what's now implemented in libdbus, GDBus and sd-bus.
If $DBUS_SESSION_BUS_ADDRESS is unset, check whether $XDG_RUNTIME_DIR/bus
is a socket owned by Flatpak's uid; if it is, use it.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2874
Approved by: alexlarsson
readlink() and readlinkat() have weird semantics (they return the
number of bytes they would have written if there was enough space,
even if that's larger than the buffer), but glnx_readlinkat_malloc()
takes care to do the right thing in all situations.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2873
Approved by: matthiasclasen
flatpak run checks if there is any previous-ids for the app and
sees if there is a corresponding app-dir in ~/.var/app/ .
If so, it renames that app-dir to the new app-id and provides
a symlink from old app-id dir to new app-id dir, and exposes
these symlinks to the sandbox. The symlink is needed because even
though the XDG_DATA_DIR and other environment variables are set
to the new ID by flatpak run, the app itself could've stored
(eg in GSettings, or other files) paths which contained the old ID.
https://phabricator.endlessm.com/T23532Closes: #2775
Approved by: alexlarsson
Uncrustify has an option "nl_func_var_def_blk" which is supposed to
ensure there's a newline character between the block of variable
definitions and the rest of the function body, but it gets confused and
thinks that the first instance of "g_autoptr" or "g_auto" being used on
a variable is the start of the function body. So this commit removes
those extra newline characters and removes that option in uncrustify.cfg
so they don't get re-added the next time uncrustify is run.
Here's the command I used:
perl -0777 -i -pe 's/\n(\n\s*g_auto\()/\1/g' `git ls-tree --name-only
-r HEAD | grep \\\.[ch]$ | grep -v common/valgrind-private.h |
grep -v app/flatpak-polkit-agent-text-listener\\\.[ch]`
I ran it again with "g_autoptr" in place of "g_auto", and made a few
manual edits to add back the newline when the g_auto* was in the middle
of a function body rather than at the top.
Closes: #2715
Approved by: matthiasclasen
Edit uncrustify.cfg to add options to remove extra newlines near opening
and closing braces, and run uncrustify again.
Closes: #2715
Approved by: matthiasclasen
We do a one-time conversion of existing dconf user settings
into a keyfile in the apps XDG_CONFIG_DIR, where the glib
keyfile settingsbackend will look for it.
Closes: #2678
Approved by: alexlarsson
Whenever we use $XDG_RUNTIME_DIR and expose it somehow in the sandbox
we fully resolve the path, because if (as happens on gentoo for instance)
it contains /var/run -> ../run, then flatpak thinks we need to
add the /var/run symlink in the runtime even though we already
exposed that.
Closes: #2710
Approved by: matthiasclasen
As shown by CVE-2019-5736, it is sometimes possible for the sandbox
app to access outside files using /proc/self/exe. This is not
typically an issue for flatpak as the sandbox runs as the user which
has no permissions to e.g. modify the host files.
However, when installing apps using extra-data into the system repo
we *do* actually run a sandbox as root. So, in this case we disable mounting
/proc in the sandbox, which will neuter attacks like this.
This file lists the directories that are remapped in the sandbox,
allowing fontconfig to use the correct cache identifier for the
host-side caches.
As an example, this generates:
```
$ ./flatpak run --command=sh org.gnome.gedit
[📦 org.gnome.gedit flatpak]$ cat /run/host/font-dirs.xml
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<remap-dir as-path="/usr/share/fonts">/run/host/fonts</remap-dir>
<remap-dir as-path="/home/alex/.fonts">/run/host/user-fonts</remap-dir>
</fontconfig>
```
Closes: #2635
Approved by: alexlarsson
We want to move away from using dconf inside the sandbox,
and instead use the keyfile backend for GSettings, which
has gained the capability to read defaults and locks.
This change makes the dconf database contents and locks
available in a suitable format. The files appear inside
the sandbox in the /etc/glib-2.0/settings directory.
We only export the default values for keys in the dconf
subtree whose path matches the app id, as well as prefixes
listed in paths key from the X-DConf group in metadata.
This commit adds a new dependency, since we're now linking
against libdconf.
Closes: #2295
Approved by: alexlarsson
Bubblewrap has a --chdir option to control the directory
that the command is run in. Add an argument for this to
the flatpak_run_app function, update all callers, and add
a --cwd option to flatpak run that uses this new argument.
Closes: #2443
Approved by: alexlarsson
This adds a version to the deply data format, assuming that if
there is no version then it is 0. Also extends all loaders so that
it can specify a required version, with the goal that most users
are fine with old versions, but if you need more recent we have
a (costly) conversion process to upgrade (will be added later).
The library and the flatpak list/info commands require the most
current version for full info, all other users can use any version.
Also, as part of this we now pass the ref to flatpak_load_deploy_data()
as this will be needed later for the backwards compat support.
Closes: #2409
Approved by: alexlarsson
Differentiate sandbox shells by a custom prompt.
We set FLATPAK_ID to the app id, and PS1 to a prompt
using it. PS1 can be overridden by runtimes or --env.
Closes: #2447
Approved by: alexlarsson
There are some use cases where apps might legitimately need
to know the host values of xdg variables. Since we use them
for our own purposes, we can't just propagate them as-is.
Instead, set HOST_XDG_{DATA,CONFIG,CACHE}_HOME if the corresponding
xdg variables are set on the host.
Closes: #2424Closes: #2440
Approved by: alexlarsson
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.
