| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
`runCommandLocal` was added to nixpkgs in
https://github.com/NixOS/nixpkgs/pull/74642
to speed up trivial `runCommand` derivations by always building them
locally. We have a few places where that’s good to use.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far I mostly used this implementation for the games we have packaged,
where we pretty much patch out all commands that execute external
programs.
However in order to be useful in a more generic way, it makes sense to
provide a /bin/sh implementation, especially when you have to deal with
scripting languages.
I'm using dash here, because it's a more minimal implementation rather
than the default shell (bash) we use in nixpkgs and it practically only
needs to be able to run constructs like "/bin/sh -c foo".
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to isolate processes even further it's a good idea to not let
them access information about other PIDs, eg. by enumerating /proc.
However, this still bind-mounts /sys from the root namespace, so we
might want to restrict /sys further. For our games however we will need
/sys because it is used to enumerate gamepads and other input devices.
Currently the processes will now be PID 1. I've tested this against a
few games and none of them had problems with that so far, so let's keep
it that way.
Another thing we might want to add and which currently isn't there is a
subreaper, which is useful if we have a process that leaves zombie
processes around.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For example the store path of libGL-1.0.0 is a symlink pointing to
libglvnd-1.0.0 right now on my machine.
If we have such a symlink the sandbox would just silently skip it and
only mount the *resolved* path instead of creating the symlink leading
to the target.
Now whenever bind_mount() with the resolve argument being true is used,
we create all the symlinks leading to the target path determined by
realpath().
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the introduction and move of a few packages to use the sandbox, we
no longer have XDG desktop entries, because the sandbox only creates
wrappers for all programs in $drv/bin.
This now also copies the XDG desktop files and replaces absolute paths
to binaries to refer to the sandboxed binaries.
I also modified the test to go through the XDG desktop file by default
so we can ensure that this works properly.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We only handle XDG_DATA_HOME and XDG_CONFIG_HOME, but we've missed
XDG_CACHE_HOME. While the latter is used very rarely as it doesn't
matter a lot if it ends up within a tmpfs anyway. However if the cache
directory gets pretty large we might run out of space.
Not only do we now have proper fallbacks but this also adds tests for
all of the XDG environment variables we're using.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
| |
In 38d3fe573f4d0ad2115eaca71a0b8f67fd01a580 we have moved the sandbox
builder to the top-level vuizvui namespace so we no longer need to do
weird workarounds by providing an empty game configuration.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
We have excluded all tests within the games directory from being built
by Hydra, rightfully so because they're proprietary. However our sandbox
is *not* proprietary so we want to have it tested.
Besides, we might want to use that sandbox for other things rather than
just games in the future, which saves us that rename later ;-)
Signed-off-by: aszlig <aszlig@nix.build>
|
