- Dec 17, 2020
-
-
Simon McVittie authored
To work around older versions of GLib having a potential deadlock in their fd-closing code due to use of non-async-signal-safe functions in the forked child process, the Flatpak-derived code we're using here uses a simple, naive implementation of closing fds: it iterates through every possible fd, up to the rlimit. Unfortunately, Wine users sometimes set their fd rlimit very high (typically around a million), because the "esync" mechanism in Proton's Wine needs a lot of fds. The time taken by each individual syscall is not significant, but when we do a million of them, it adds up. This is arguably a misconfiguration - the recommendation is now to have a soft rlimit of 1024 and a hard rlimit of about a million, so that only processes that opt-in to dealing with a million fds have to be aware of them - but a significant number of misconfigured systems probably still exist. We don't actually *need* to close all the fds here: there's no security boundary, so giving the child access to unnecessary fds isn't a privilage gain; the parent process outlives the child, so leaking fds won't result in them never being closed; and in any case we're reasonably careful to set CLOEXEC on all our fds. So let's just not close them. In particular, this can save literally a million syscalls per helper subprocess invocation (it's not often I get to say that!), reducing pressure-vessel-wrap launch time by 90% on a system with the high fd limit (about 70 seconds down to 7). With the recommended soft limit of 1024, the speedup is less dramatic, but it still takes off nearly 10% (about 6 down to 5.5). Resolves: https://github.com/ValveSoftware/steam-runtime/issues/323 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 17, 2020
-
-
Simon McVittie authored
If we want to deal with strange operating systems that use a non-standard filename for ld.so.cache, we'll have to special-case it. There's little extra cost to doing this because we already need to understand how ld.so.cache works, to be able to generate our own with different search paths. In situations where we just want a quick container to be able to inspect the runtime, we can deal with this by mounting all of /etc read-only. For the final container, we already iterate over all the files in the runtime's /etc, which will "naturally" include ld.so.cache and alternatives. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 29, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 09, 2020
-
-
Simon McVittie authored
This is preparation for combining pressure-vessel with steam-runtime-tools. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 02, 2020
-
-
Ludovico de Nittis authored
The filesystem that is providing /usr might not be mounted in the same place in the current namespace, and on the host system where bwrap will be run. If it isn't, we need to use one path to do file I/O when inspecting it, but pass a different path to bwrap. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Sep 01, 2020
-
-
Simon McVittie authored
The default for a FlatpakBwrap object is to copy the calling environment as a base for the environment that it will build up. However, that's wrong if we are going to merge more than one FlatpakBwrap together: the merged FlatpakBwrap's argv will be appended to the destination FlatpakBwrap, but the merged envp will overwrite the corresponding variables in the destination. Avoid this by making sure that every time we merge two FlatpakBwrap objects, one of them has an empty environment. Resolves: T23422 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 29, 2020
-
-
Simon McVittie authored
If the wrapped command prints structured data to stdout, we don't want to corrupt its output stream. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
As noted in Flatpak and in GNOME/glib!490, there is a bug in GLib < 2.60 where g_spawn_* can sometimes deadlock while closing fds in a multi-threaded application. Work around this by making the affected fds close-on-execute ourselves, much like Flatpak does. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- May 21, 2020
-
-
Simon McVittie authored
We'll need those if we want to run ldconfig. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Mar 04, 2020
-
-
Simon McVittie authored
This sketches out roughly how we'd do this if we were in a container such as a Flatpak environment, rather than on the host system. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 26, 2020
-
-
Simon McVittie authored
We want all the libQUAL directories, including lib32 and lib64 (and in principle also libx32, libn32 etc.), but we specifically don't care about libexec. Real systems don't usually symlink /usr/libexec into the root directory. If we create a /libexec symlink, the only effect it might have is that game developers start relying on it, which we certainly don't want. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 06, 2020
-
-
Simon McVittie authored
Non-OFD locks don't propagate across fork(), and bwrap needs to clone() itself (which behaves like fork() in this respect) to separate itself into a parent outside the container and a child inside the container. This change adds a weak dependency on Linux 3.15. If we run on an older version, everything should still *work*, but there will be a short period of time during which we have already decided to use the runtime, but it is not locked (and in particular not protected from deletion). Fixes: 959fd338 "wrap: Take out a lock on the container's runtime for the duration" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 12, 2019
-
-
Simon McVittie authored
This ensures that we include it in every translation unit. Rename it to _pressure-vessel-config.h to avoid accidentally including the wrong config.h in the presence of submodules. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 11, 2019
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 10, 2019
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 04, 2019
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-