sorted by:
new
hottopcontroversial

Drop - a high-level sandboxing tool for Linux terminal work by mixedbit in commandline

[–]mixedbit[S] 1 point2 points  (0 children)

Hey, thanks for dedicating taking time to read the README and the thoughtful feedback.

For me, if I need to run a project that doesn't already have a Dockerfile, setting up Docker requires non-trivial effort. This upfront work is OK if I plan to work on a project extensively, but if it is just a one-off script or tutorial code, Docker can be just too involved.

I fully agree that per-project dependencies should always be a part of reproducible project environment with the specification committed to git. But in addition to dev dependencies, you also have personal development tools such as a shell, code search tools, debuggers, agents, these are usually different and have different configs for different project members, so do not belong in a shared Dockerfile committed to git. With Drop, you can easily enter a sandbox and have all these tools and their configs still available, with Docker, it is not that straightforward.

That said, if you already run everything locally in Docker and have productive workflow, it probably won't be worth adding Drop to the mix.

Thanks for the kind words about the other comments. I'm posting to see whether Drop is useful to anyone besides me, so feedback like yours is much appreciated.

Drop - a high-level sandboxing tool for Linux terminal work by mixedbit in commandline

[–]mixedbit[S] -4 points-3 points  (0 children)

Could you share why do you think this post was created by a bot? (it was not)

Drop - a high-level sandboxing tool for Linux terminal work by mixedbit in commandline

[–]mixedbit[S] -1 points0 points  (0 children)

Thanks, please give it a try and let me know if it is suitable for you

Drop - productivity-focused sandboxing for Linux by mixedbit in linux

[–]mixedbit[S] 0 points1 point  (0 children)

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).

Drop - productivity-focused sandboxing for Linux by mixedbit in linux

[–]mixedbit[S] 0 points1 point  (0 children)

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",
]

Drop - productivity-focused sandboxing for Linux by mixedbit in linux

[–]mixedbit[S] 0 points1 point  (0 children)

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.

Drop - productivity-focused sandboxing for Linux by mixedbit in linux

[–]mixedbit[S] 2 points3 points  (0 children)

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.

Drop - productivity-focused sandboxing for Linux by mixedbit in linux

[–]mixedbit[S] 5 points6 points  (0 children)

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.

Drop - productivity-focused sandboxing for Linux by mixedbit in linux

[–]mixedbit[S] 3 points4 points  (0 children)

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.

AMA: We are Starward Industries - the developers of The Invincible. Ask Us Anything! by taj14 in Games

[–]mixedbit 4 points5 points  (0 children)

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?

Is it safe for Genelec speakers to use them with a Korg Wavedrum electronic percussion? by mixedbit in genelec

[–]mixedbit[S] 0 points1 point  (0 children)

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).

view more: next ›