Add '--usb' and '--nousb' to the FlatpakContext option group.
Map these parameters to either the enumarable list, or the hidden
list, of a new "USB Devices" group in the metadata key file. It looks
like this:
```
[USB Devices]
hidden-devices=cls:01:*;
enumerable-devices=vnd:0fd9+dev:0080;vnd:0fd9+dev:0080;
```
Flatpak itself does not use these values, they're meant to be used
by e.g. XDG Desktop Portal to filter which devices the app can see
through the USB portal.
Hidden devices must always take precedence over enumerable devices.
This is heavily inspired by https://github.com/flatpak/flatpak/pull/4083
Co-Authored-By: Georges Basile Stavracas Neto <georges.stavracas@gmail.com>
Co-Authored-By: Ryan Gonzalez <rymg19@gmail.com>
Signed-off-by: Hubert Figuière <hub@figuiere.net>
We now resolve the zoneinfo and always make it available at
/usr/share/zoneinfo in the sandbox so we unset TZDIR to get flatpak apps
looking at the right directory.
This is more compliant with FHS specification. Most notably, /etc
is not appropriate to hold distro configuration, which is a common
use for the remotes.d feature. It is better practice to put things
under /usr/share, and let the system administrator modify /etc to
their will, of course giving them priority.
Update documentation to reflect this change.
In the process, move to use g_build_filename
This adds a new `usb` device in the list to grant access to the whole
USB bus. This is narrower than `all` and should be enough for
anything accessing the USB directly (i.e. using libusb or equivalent).
This doesn't grant access to synthesized devices, i.e those exposed
in `/dev` but using USB, including but not limited to USB serial, webcams,
hidraw, hid, sound.
Close#4405
Signed-off-by: Hubert Figuière <hub@figuiere.net>
This option allows the application (or subsandbox) to own the specified
name on the a11y bus. This will be useful for WebKit, that has a strict
security need that the Web processes cannot talk or see each other.
An alternative approach would be to make xdg-dbus-proxy permissions
modifiable at runtime, but that seems a lot riskier than this. Owning
a well known name based on the app id has proven to be a robust and
secure approach after all.
To include all languages, the languages key must be set to `*all*`, not
`all`. That was apparently intended to provide symmetry with how the
value is represented in the output of `flatpak config`.
Following on from b8d8d80c61, add more environment variables used by
the Vulkan loader which expect paths to be provided.
These paths are typically referencing the host filesystem; if the user
is referencing paths only available in the sandbox, they can use --env
or overrides for them.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Similar to how b8d8d80c61 inhibited passthrough of environment
variables pointing the Vulkan loader towards a specific ICD, do the same
for the EGL paths used by libglvnd to discover the GL driver to use, as
well as for NVIDIA's EGLStream shim.
These paths are typically referencing the host filesystem; if the user
is referencing paths only available in the sandbox, they can use --env
or overrides for them.
Signed-off-by: Daniel Stone <daniels@collabora.com>
I don't think this env var makes much sense to pass into the sandbox
for similar reasons to LD_LIBRARY_PATH. Libraries from the host
just aren't relevant.
Users can still pass `--env=LD_PRELOAD=/foo` to use this functionality.
As discussed in #5695, I think we're reaching a point where removing
Autotools is preferable to fixing it.
1.14.x continues to use Autotools, so platforms whose Meson version is
too old can stay on that branch until it becomes unsupported. We have
a very conservative Meson dependency (Ubuntu 20.04).
Signed-off-by: Simon McVittie <smcv@collabora.com>
1. For security context creation, only relies on WAYLAND_DISPLAY, do not
use WAYLAND_SOCKET since the file descriptor defined by WAYLAND_SOCKET
can be only consumed once.
2. Due to the incompatiblity between WAYLAND_SOCKET and the security
context, add a new permission --socket=inherit-wayland-socket
to limit the usage of WAYLAND_SOCKET to an opt-in feature. Only when
this flag is set, WAYLAND_SOCKET will be passed to the sandbox.
3. When WAYLAND_SOCKET is not inherited, set FD_CLOEXEC to avoid it to
be leaked the to sandbox.
Closes: #5614
In order to maintain a system over time update automatically removes any EOL runtimes that are unused.
This extends it to also remove any autopruned refs. In practice this means removing no longer used driver versions as the system is updated.
Closes#5261
These environment variables inform the Vulkan loader on where to find driver files.
Since they typically point to locations on the host filesystem, any application that
attempts to load Vulkan within the flatpak sandbox would break with these set.
This mostly replaces `flatpak_transaction_add_rebase()`. It’s necessary
because the uninstall op for an eol-rebased app needs to be linked to
the install/update op for the rebased app, otherwise one op can proceed
after the other has failed (or they can be run in the wrong order) and
result in the old app being uninstalled but the new one not installed.
The following commit will port the internal flatpak `FlatpakTransaction`
subclasses to use it. Other consumers of `FlatpakTransaction` (such as
gnome-software) will have to be ported as well.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3991
If the `GDK_BACKEND` environment variable is present and it's value does
not match the Wayland and X11 socket configuration, then a GTK app will
fail to run since it will only consider the display backend from the
environment variable.
This should probably be extended to cover other display environment
variables such as `QT_QPA_PLATFORM` for Qt and `SDL_VIDEODRIVER` for
SDL. However, I've only tested this with GTK applications.
This variable contains paths to load GIO modules from. For the most
part, they refer to paths outside of the sandbox or if they happen
to be in the sandbox, would contain modules that are incompatible with
the sandbox runtime (ie. different libc).
While I've not found programs that would crash outright, it may cause
unexpected behaviors (eg. Apostrophe not being able to render math in
preview panel).
This variable is set by NixOS for its dependency boxing.
This variable is typically used to configure the use of a custom
set of XKB definitions. In those cases, it's mostly meant for the
X11 server or Wayland compositor. NixOS is known to employ this
variable for their custom XKB layout implementation.
When the path it points to is unreachable (due to the sandbox),
most GTK+/Qt applications will crash on Wayland.
Unsetting this does not seem to negatively impact the use of custom
XKB layouts with Flatpak applications.
If this environment variable is set on the host, it's going to mess up
authentication in the sandbox. For example, if the host has:
KRB5CCNAME=KCM:
then the sandboxed process will try to use the host KCM socket, which is
not available in the sandboxed environment, rather than the gssproxy
socket that we want it to use. We need to unset it to ensure that
whatever configuration we ship in the runtime gets used instead. We have
switched the GNOME runtime to use an empty krb5.conf and it works as
long as we don't break it with this environment variable meant for the
host.
Save folks a few keystrokes. There is a command which already has a '-u'
option, document-export, but it doesn't support --user so there should
be no conflict. However '-s' is used by the info command among others,
so we can't use that for --system.
We already allow normal apps to own MPRIS names but subsandboxes could not.
This allows them with the same dbus restrictions that they must be
prefixed by $app_id.Sandboxed.
This will be used by WebKitGTK.
When Flatpak's P2P updates support was replaced with the "sideloading"
implementation in 1.7.1, a new server side repo config key
"deploy-sideload-collection-id" was added which gets set when you pass
"--deploy-sideload-collection-id" to "flatpak build-update-repo", and
has the effect of setting "xa.deploy-collection-id" in the repo metadata
that is pulled by clients, which itself causes a collection id to be set
on the remote for clients using Flatpak >= 1.7.1.
This commit adds an analogous key in flatpakref and flatpakrepo files,
so the collection id can be set when the remote is configured, rather
than later on when the repo metadata is pulled and acted upon. As before
with DeployCollectionID, it has no difference in function compared to
DeployCollectionID or CollectionID and the only difference is which
Flatpak versions are affected.
It would've been better if this were added in 1.7.1 when the sideload
support was added, but alas here we are.
(Also update the docs and unit tests)
This makes it a lot easier to give guidance on using `flatpak run -d` or
`flatpak-coredumpctl`, because there's an easy way to install the
relevant refs.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
As discussed in #4848, this disables fuzzy matching when the string
given has a period in it. So for example "flatpak install org.mozilla"
would not offer "org.mozilla.firefox" even though the string given is a
substring of the app ID. This is desirable because it helps ensure fuzzy
matching is only used when the user intended to use it.
As with the previous commit that fixed#4829, this does technically
break backwards compatibility, but only in an interface intended for
interactive use by a human, not an interface that's used
programmatically, so it seems okay.
