In ostree I maintain what I consider a "baseline" set of compiler
warnings that should *always* be fatal for a modern C project.
I noticed while working on a previous patch that a `-Werror=format`
warning wasn't fatal.
There are a few that are really, really important like
`-Werror=missing-prototypes`. I also take some like `-Werror=misleading-indentation`
which already caught some bugs. See also https://lwn.net/Articles/678019/
If you do something like:
flatpak build --talk-name=org.foo.Bar appdir
Then we now spawn a dbus proxy for the app.
However, we don't do this by default, even if the
runtime or the app metadata allows this, because
we want builds to normally be disconnected from
the build host.
At the moment, flatpak applications are only given FamilyLocal family
xauth cookies from the Xauthority file. This is so, the sandboxed
application doesn't inadvertently get access to displays on other
computers.
But FamilyLocal isn't the only xauth family that's local. FamilyWild
entries can be local as well.
Furthermore, FamilyWild entries are preferable to FamilyLocal entries
when found, because they don't break if the system hostname is changed.
This commit makes FamilyWild xauth entries get propagated in the same
way as their FamilyLocal counterparts.
It turns out that it is impossible for to get ptrace capabilities
for child user namespaces in the current kernel if the user
namespace is created as root, which is what happens when bwrap
is setuid root (see https://github.com/flatpak/flatpak/issues/557
for details).
This is very problematic, as ptrace rights controls access to
/proc/$pid/root which is what we base the detection of peer
app id and rights on for portals.
For now, we disable user namespaces (except for the case of
unprivileged user namespaces, where it is necessary and works).
If we have network access, then nvidia talks to the xserver
and for some reason it then also needs /dev/nvidia-modeset.
So, lets add that to the dri device list.
If directory is "foo" and the extension id ends with ".ext" and
subdirectory-suffix is "sub" then the extension point will
be "/usr/foo/ext/sub" rather than just "/usr/foo/ext".
This is very useful when the extension point naming scheme is
"reversed". For instance, this happens for the /usr/share/themes directory.
An extension point for a gtk3 theme would be in /usr/share/themes/$NAME/gtk-3.0,
which could be achived by using subdirectory-suffix=gtk-3.0.
If your extension points set this, then each extension will have
the corresponding subdirectory added to LD_LIBRARY_PATH.
We also support a priority property in the ExtensionOf group
in the extensions themselves to set the search order.
If we sort, or subset the extensions we use, then we can't just
set need_tmpfs on the first one, instead do the checking
for the first one when we're applying the extensions.
On unmonitored systems (if the session helper is not available), we
currently decide whether to create a symlink or a read-only bind mount
for /etc/localtime based on whether that's a symlink in the host or
not, but we don't check whether that symlink would be reachable in
the sandboxed environment, which might lead to bad situations.
This patch adds some extra checks relying on GFile's API to check
whether that symlink would be reachable before making the final
decision: if it's not, then do a bind mount despite of the file
being a symlink in the host.
https://github.com/flatpak/flatpak/issues/409
It turned out that some sources where bind-mounted read-write
which should have been read-only:
* Extensions
* Fonts
* resolv.conf
* localtime
* machine-id
Many of these are not generally writable by the user, but
some are, which is pretty bad. For instance if the an
app is user-installed it will be able to write to its
locale data.
We fix this by using --ro-bind where needed.
We make /etc just a symlink to /usr/etc when we're building a runtime
and /etc is supposed to be writable. Otherwise the bind-mount we
normally have there don't allow use to replace existing files in /etc.
The socket directory then ended up in $HOME which was read-only, so
we couldn't create the socket. We solve this by putting the sockets
in a subdirectory and always making this directory writable in the
proxy.
If the homedir is on a symlink (say /home -> /var/home) but the homedir
is in /home, then we shouldn't create a directory in /home because
then the symlink creation will fail. Instead we move the homedir
creation to the end, where we will create it in the symlink if needed.
This should fix https://github.com/flatpak/flatpak/issues/493
If you are exposing a symlink, say /link (-> /target) and
also a child of it, say /link/child, then we run into dependency
issues. For instance, the /link symlink is created, pointing to /target,
but then we try to to create /link/child before the /target
bind mount is setup, which will fail.
We work around this by adding a level, and the dependency of a symlink
(/target in the above case) will always be handled first. This isn't
a perfect solution, but is likely to be good enough in practice.
This change fixes GCC compiler warnings where a cleanup function was
specified on an uninitialised pointer, which in the view of GCC could
result in an errornous free of uninitialised memory, if the functions
that initialise them do not return NULL.
Signed-off-by: Ikey Doherty <ikey@solus-project.com>
Apps may rely on /var/tmp not being in ram, for instance when
downloading large files. See for instance:
http://0pointer.net/blog/projects/tmp.html
We make /var/tmp point to ~/.var/app/cache/tmp so that each app get
its own instane, and so that its cleared whe removing xdg-cache-dir
for the app.
These make no sense, we don't want to modify the runtime, and
we can't create parent directories there anyway which can cause
issues like https://github.com/flatpak/flatpak/pull/433
When no session helper is available (e.g. running flatpak run from a
socket-activated service unit), we need to be extra careful before
making these two files appear inside the sandbox. Otherwise, if they
are not reachable on the host system (or just symlinks to non-existent
targets), flatpak won't be able to create the sandbox, which will fail
due to a "No such file or directory error".
https://github.com/flatpak/flatpak/issues/409
We already kind of support this by exposing the parent directory,
so this isn't really less secure, and you should not be able to
access it unless your user is allowed to anyway.
This lets it work during early setup phase when the new root is at
/newroot. This allows us to create things in /var/run with
e.g. --filesystem=/var/run/foo.
If the app is explictitly given access to a subdirectory of
one of the xdg config/cache/data directories, with read-write
(or create) access, then also bind-mount that directory
into the corresponding .var/app/$APPID directory.
This allows apps that want it to keep re-using global directories
for storing per-app information.
For instance, if your app uses "~/.config/foo" to store configuration
data, then you can use --filesystem=xdg-config/foo, which will look
for the directory, and if it exist, let the app access it, as well
as mirror the content in ~/.var/app/$appid/config/foo.
You can also use a ":create" to enforce the directory to be created
and thus always do the mapping.
This way you can't e.g. modify your or other applications
and runtimes. If you really need to to this, your
app can explicitly request access to this directory.
If we're specifying --filesystem=/some/path, where the final element
in the path is a symlink we need to special case this. We used
to rely on bubblewrap resolving the symlink for the source and
creating a bind mount directly to that, but this does not work
if the parent directory is already visible in the sandbox, because
we can't bind-mount on top of the pre-existing symlink.
Instead we detect this the symlink early, resolve the target and
bind mount in that, then we create a real symlink in its place.
However, that doesn't work if the paren't *doesn't* exist, so
we have to check for this and not create the symlink if it is
already going to be visible in the sandbox.
This allows you do do something like
flatpak build-finish --add-policy=subsystem.key=v1 --add-policy=subsystem.key=v2
Which maps to this metadata keys:
[Policy subsystem]
key=v1;v2;
You can also --remove-policy to remove values from a key.
The policy values are parsed from the app and runtime metadata, and
are overridable by per-app overrides and on the command line, however
the values are never used by flatpak. They do end up in the flatpak-info
file for the running application though, so external agents can look
at them.
These
This means you can do:
flatpak run org.freedesktop.Sdk
to get a shell in a sandbox with that runtime, but with an
empty /app.
You can also specify a particular runtime branch and command like so:
flatpak run --command=ls org.gnome.Platform//3.22 /
This adds a new "multiarch" feature which allows bundling e.g. 32-bit
binaries to be run in a x86_64 environment. By default, the seccomp
filter is configured to allow only the native architecture. When the
"multiarch" feature is enabled, the filter will be configured to allow
running binaries of additional architectures supported. For x86_64, this
allows x86 32-bit binaries; and for Aarch64, allows 32-bit ARM binaries.
Application bundles can use the feature e.g. in order to ship 32-bit
binaries alongside with a mostly-64-bit application. This is particularly
interesting when for applications that might launch themselves prebuilt
programs for which 64-bit versions do not exist. For example, the Steam
application is available as a 64-bit executable, but some of the games
available are 32-bit only. A Flatpak bundle for the Steam application
with "multiarch" enabled is able launch the 32-bit games -- without the
feature enabled, the seccomp filter would prevent them from running.
Multiple-architecture support is enabled by adding the "multiarch" value
for the "features" key in the metadata file for a Flatpak:
[Context]
features=multiarch;
The corresponding "--allow=multiarch" command line option is supported
in "flatpak build-finish" as well.
Colin Walters