沙箱权限#

flatpak的一个主要目标就是通过应用间的隔离来提高桌面系统的安全性。这通过使用沙箱来实现，默认地，应用运行的环境对主机的访问很有限。这包括：

  • No access to any host files except the runtime, the app, ~/.var/app/$FLATPAK_ID, and $XDG_RUNTIME_DIR/app/$FLATPAK_ID. Only the latter two being writable.

  • 无法访问网络。

  • 无法访问任何设备节点的（除了 /dev/null ，等等）。（译者注：可能有访问所有null设备的权限）

  • 无法访问沙箱之外进程

  • 有限的系统调用。举个例子，应用无法使用非标准的网络socket或者ptrace其他进程。

  • 有限地访问D-Bus实例的session——一个应用在总线上只能拥有它自己的名字。

  • 无法访问主机服务，像X11，system D-Bus或PulseAudio这些。

大部分应用需要访问这些资源。这些主要是在finishing构建步骤完成的，通过清单文件（查看 清单）的 finish-args 部分来配置。

门户（译者注：英文portals）#

Portals have already been mentioned in 基本概念. They are a framework for providing access to resources outside of the sandbox, including:

  • 用一个本地的文件选择对话框打开文件

  • 打开URL

  • 打印

  • 显示通知

  • 截取屏幕

  • 禁止用户会话结束、暂停、空转或切换。

  • 获取网络状态信息

在许多情况下，门户通过使用系统组件在获取访问某些特定资源的权限之前隐式地向用户获得了许可。举个例子，在打开一个文件的时候，用户用文件选择对话框进行文件选择，可以理解为隐式地授予了应用对选中文件的访问。

这种方式使得应用在需要访问大量数据或服务时避免重复配置， 也让用户可以掌控（译者注：知悉，了解）他们的应用的访问权限。

Interface toolkits like GTK3 and Qt5 implement transparent support for portals, meaning that applications don’t need to do any additional work to use them (it is worth checking which portals each toolkit supports). Applications that aren’t using a toolkit with support for portals can refer to the xdg-desktop-portal API documentation for information on how to use them.

权限手册#

虽然应用程序开发人员可以控制他们想要配置的沙箱权限，但是鼓励进行良好的实践。举个例子，Flathub主机托管服务对权限的使用提出了要求，如果使用了某些权限，主机上的软件可能会警告用户。

后面的手册描述了哪些权限可以任意使用，哪些可以根据需要使用，哪些应该避免使用。

标准权限#

以下权限提供了应用通常需要访问的基本资源，因此可以自由使用：

  • --share=network - 访问网络

  • --socket=x11 - show windows using X11

  • --socket=fallback-x11 - show windows using X11, if Wayland is not available, overrides x11 socket permission. Note that you must still use --socket=wayland for wayland permission

  • --share=ipc - 和主机共享IPC命名空间 (对于X11是必要的)

  • --socket=wayland - 使用Wayland显示窗口

  • --device=dri - OpenGL 渲染

  • --socket=pulseaudio - 使用PulseAudio播放音频

D-Bus访问#

避免使用 --socket=system-bus 或 --socket=session-bus 访问整个总线，除非应用是一个开发工具。

Ownership

应用会自动为他们自己命名空间授予访问权限，通常不需要有所有权，尽管如此还是有少量的例外，例如使用 MPRIS来提供媒体控制 。

Talk

Talk permissions can be freely used, although it is recommended to use the minimum required.

文件系统访问#

It is common for applications to require access to different parts of the host filesystem, and Flatpak provides a flexible set of options for this. Some examples include:

  • --filesystem=host - 访问主机的常规文件，不包含一下提到的主机操作系统或者系统内部

  • --filesystem=home - 访问用户home目录

  • --filesystem=/path/path - 访问特定路径

  • --filesystem=xdg-download - 访问特定的XDG文件夹

As a general rule, Filesystem access should be limited as much as possible. This includes:

  • 尽量使用门户来代替文件系统访问。

  • 尽量使用读取权限来访问，使用 :ro 选项。

  • 如果一定要访问home目录，只使用XDG目录访问。

The full list of available filesystem options can be found in the Sandbox Permissions Reference. Other filesystem access guidelines include:

  • --persist=path 选项可以用来将用户目录映射到沙箱的文件系统。这可以避免配置整个home目录访问权限。并且对于在硬编码使用 ~/ 文件路径的应用程序非常有用。

  • If an application uses $TMPDIR to contain lock files you may want to add a wrapper script that sets it to $XDG_RUNTIME_DIR/app/$FLATPAK_ID.

  • 应该避免与非flatpak安装的应用共享配置。

如上所述， host 选项实际上没有提供主机文件系统的完整访问。主要的规则是：

  • 这些目录是屏蔽掉的： /lib , /lib32 , /lib64 , /bin , /sbin , /usr , /boot , /root , /tmp , /etc , /app , /run , /proc , /sys , /dev , /var

  • /run/media 例外

  • 这些目录被挂载到 /var/run/host : /etc ， /usr

许多目录被屏蔽的原因是他们已经在沙箱里存在了：例如 /usr 或者是一些在沙箱中不可用的目录。

The home permission also has exceptions as it does not grant access to the subdirectories for other applications in ~/.var/app/.

设备访问#

尽管不理想， --device=all 可以用来访问控制器和网络摄像头之类的设备。

dconf访问#

As of xdg-desktop-portal 1.1.0 and glib 2.60.5 (in the runtime) you do not need direct DConf access in most cases.

As of now this glib version is included in org.freedesktop.Platform//19.08 and org.gnome.Platform//3.34 and newer.

If an application existed prior to these runtimes you can tell Flatpak (>= 1.3.4) to migrate the DConf settings on the host into the sandbox by adding --metadata=X-DConf=migrate-path=/org/example/foo/ to finish-args. The path must be similar to your app-id or it will not be allowed (case is ignored and _ and - are treated equal).

If you are targeting older runtimes or require direct DConf access for other reasons you can use these permissions:

--filesystem=xdg-run/dconf
--filesystem=~/.config/dconf:ro
--talk-name=ca.desrt.dconf
--env=DCONF_USER_CONFIG_DIR=.config/dconf

With those permissions glib will continue using dconf directly.

If you use a newer runtime where dconf is no longer built and still need it you will have to build the dconf GIO module and set --env=GIO_EXTRA_MODULES=/app/lib/gio/modules/.

gvfs access#

As of gvfs 1.48, the gvfs daemons and applications use an on-disk socket to communicate, rather than an abstract socket so that the gvfs infrastructure still works when network support is disabled in the application’s sandbox.

A number of different options need to be passed depending on the application’s use of gvfs.

--talk-name=org.gtk.vfs.* is necessary to talk to the gvfs daemons over D-Bus and list mounts using the GIO APIs.

--filesystem=xdg-run/gvfsd is necessary to use the GIO APIs to list and access non-native files using the GIO APIs, using URLs rather than FUSE paths.

--filesystem=xdg-run/gvfs is necessary to give access to the FUSE mounts non-GIO and legacy applications can use. This is what will make native files appear under /run/user/`id -u`/gvfs/.

Typical GNOME and GTK applications should use:

--talk-name=org.gtk.vfs.*
--filesystem=xdg-run/gvfsd

Typical non-GNOME and non-GTK applications should use:

--filesystem=xdg-run/gvfs

No application should be using --talk-name=org.gtk.vfs in its manifest, as there are no D-Bus services named org.gtk.vfs.