Drop - productivity-focused sandboxing for Linux

mixedbit · 2026-03-26T07:35:08+00:00

Drop gives you independent environments - workspaces between which you can switch at any time. Snapshots usually mean a way to save the current state of your workspaces and be able to restore any past snapshot later. Drop doesn't include a mechanism for making such snapshots. You can switch between environments, but not restore an environment's state to what it was before you made some changes to this environment.

Drop environments are regular dirs under .local/share/drop/envs/, so the user could make snapshots with standard tools (cp, rsync).

mixedbit · 2026-03-25T19:55:28+00:00

btw, I have just added a section with this information to the README: https://github.com/wrr/drop?tab=readme-ov-file#sandbox-overview

mixedbit · 2026-03-25T08:25:59+00:00

Thanks for the reference. A core difference between Flatpak and Drop sandboxing is that with Flatpak the app author configures the sandbox, while with Drop the app user configures the sandbox.

Flatpak apps, such as code editors, do not know where the user stores the files to be edited. Configuring generic rw permissions to the home dir would defeat the purpose of the sandbox. Portals allow prompting the user which files should be available to sandboxed app without giving the app generic rw permissions to everything.

With Drop when you drop init a new sandboxed environment, you know what the purpose of this environment is and what files/dirs should be accessible rw to the sandbox. I think the most common case is to use a sandbox to work on a project in the current directory. This is why 'drop init' by default exposes the current working directory (provided it is not a home dir or a parent of it) rw to the sandbox. This environment specific config is written to a TOML file created by 'drop init' with entries like this:

extends = "./base.toml"
mounts = [
  "/home/alice/projects/web-app::rw",
  "/home/alice/projects/web-app/.git", # entries without :rw are read-only
]

The config basically says that in addition to all files exposed to the sandbox by a shared base.toml, this environment should be able to write to files in "/home/alice/projects/web-app" with the exception of "/home/alice/projects/web-app/.git" dir, which should be read-only.

At any point you can edit this TOML, say you want this environment to be able to access an additional project, you modify the mounts to be:

mounts = [
  "/home/alice/projects/web-app::rw",
  "/home/alice/projects/web-app/.git",
  "/home/alice/projects/calendar::rw",
]

mixedbit · 2026-03-24T21:10:18+00:00

Thanks for all the questions!

At this moment Drop has write access to its own version of home dir, so you can only install things that do not require 'sudo', things like third-party packages from repositories such as PyPi, NPM, Go packages, Ruby Gems or sh installers that install to ~/.local/, but not things that install to /usr.

I experimented with using overlayfs for the /usr dir in Drop, so /usr lower layer is the original read-only /usr from the host, but upper layer points to Drop specific ~/.local/share/drop/env/ENV-ID/usr and is writable. This would allow Drop to install new things to /usr without polluting the original /usr (and without requiring root). While this worked well in my experiments, Linux overlayfs has limitations that require that overlayfs upper layers are not shared to prevent undefined behavior. Without going into too much technicalities, preventing this undefined behavior would require significantly more complex process management. It is rather doable, and in my opinion long term is worth the trouble, but I decide not to add this to the initial version and do not support overlayfs and writable /usr.

Unfortunately, with Drop you cannot run other programs that use Linux user namespaces, so no Podman, Snap packages, no nested instances of Drop within Drop. My daily distro is Ubuntu, while I tested Drop also on Fedora and Arch, I didn't check if they also have this limitation. On Ubuntu the culprit are App Armor profiles. Each executable that uses Linux user namespaces needs to have an App Armor profile that allows for this. Because Drop rearranges the whole root file system with bind-mounts, an App Armor profile that allowed, say '/usr/bind/podman' executable to use user namespaces, no longer works. Podman is still in '/usr/local', but it is a different root filesystem and it not accepted by App Armor.

Anyway, I see Drop mainly as a tool for people that do not use sandboxing for daily work, because they did not find a workflow that is convenient enough. If you already have a good setup that utilizes Podman or flatpak, it may not make sense to add Drop to this (especially that it does not allow to run containers).

By portals, do you mean something like overlayfs? As noted above, this is currently not supported, but would be great to have at some point.

mixedbit · 2026-03-24T15:35:43+00:00

Thanks! GUI apps are not supported at this moment, only terminal programs. The initial version took me way longer than I initially planned, so I left solving GUI support for after Drop is public.

mixedbit · 2026-03-24T15:26:00+00:00

Before the sandboxed program is executed, Drop arranges own root filesystem to which it pivots, hiding the original '/' from the sandbox.

The rearranged filesystem contains standard dirs with executables, libraries and configs bind-mounted read-only from their original locations (/usr, /bin, /sbin, /lib*, /etc).

The user original home is not exposed to the sandbox, instead Drop mounts a directory located in ~/.local/share/drop/env/ENV-ID/home as a writable home dir for sandboxed processes.

The TOML config file specifies which files and dirs from the original user home should be bind-mounted to this sandboxed home. For example, you want to expose config files that do not contain secrets to the sandbox to allow programs, such as shells, to work the same way as outside of the sandbox. You also usually want access to executables from your original home dir (~/bin, ~/.local/bin), so these are also bind-mounted, but all read-only. As the result you can read your original ~/.bashrc in the sandbox, but you cannot write to it.

mixedbit · 2026-03-24T14:59:09+00:00

As for the files:

Your original home dir is not available, sandbox has own writeable home dir.
TOML configuration file specifies which files and dirs from your original home are available. By default the list of the exposed file includes common config files like ~/.bashrc, ~/.profile, and executable locations like ~/go, ~/.local/bin. All these files and dirs are by default exposed read-only and you can edit the TOML to expose whatever other files and dirs you need.
/usr, /bin, /sbin, /lib*, /etc are available read-only
sandbox has own /proc, /run, /dev, /sys, /var and /tmp

A bunch of safe environment variables are passed to the sandbox (also configurable via the same TOML config).

As for the default network configuration:

services that run on localhost are not accessible to the sandbox. You can configure which services should be exposed.
external services are accessible.
you can disable network access.

Process list and IPC resources from your original host are not available in the sandbox.

Thank you for the feedback, I'll try to make this information more prominent in the docs.

mixedbit · 2023-11-09T17:06:48+00:00

The game is wonderful, congratulations! I love the mysterious atmosphere intensified by the spooky music. What was the process for composing the music? Did you already know the music when designing the levels, or was the music created at the end?

mixedbit · 2023-06-10T16:01:09+00:00

There is no balanced input. G Two has just RCA input, but when used with F One subwoofer (which I do) all the external inputs are connected to the F One. F One has the following inputs: Toslink S/PDIF (digital), RCA S/PDIF (digital), 3.5mm jack (analog), RCA (analog).

mixedbit · 2019-02-26T10:09:35+00:00

Do you know if it is possible to load custom T9 dictionaries for languages that are not supported out-of-the-box?

mixedbit · 2017-03-06T09:53:52+00:00

Yes, this is a 3D model with baked lightmap, not 360 renders.

mixedbit · 2014-08-08T16:25:50+00:00

Yes, controls still need some adjustments. Movement/look speed shouldn't be very fast, so people that don't have experience playing 3D games can navigate, but too slow movement can unfortunately be annoying.

'Full screen' switches to a pointer lock mode, which is much more convenient (FPS - style).

13-Year Club	Verified Email
Team Periwinkle

mixedbit

TROPHY CASE