Skip to content

Running

Drop’s workflow is inspired by Python’s virtualenv: create an easily disposable environment, enter it, work normally - but with enforced sandboxing.

Create a new Drop environment

drop init [ENV_ID] creates a new Drop environment. If ENV_ID is missing, Drop derives the id from your current working directory path. For example:

alice@zax:~/project$ drop init 
Drop environment created with config at /home/alice/.config/drop/home-alice-project.toml

The environment gets read-write access to the directory in which drop init was run; see Sharing the project directory.

Run a sandboxed program

drop run [-e ENV_ID] [command] runs the command within the sandbox. If [-e ENV_ID] is not passed, Drop derives the id from your current working directory path.

If [command] is not passed, it defaults to $SHELL, so to start a sandboxed shell you can simply use:

alice@zax:~/project$ drop run

Within the environment the sandbox restrictions are applied:

(drop)alice@zax:~/project$ file ~/.ssh
/home/alice/.ssh: cannot open `/home/alice/.ssh' (No such file or directory)
(drop)alice@zax:~/project$ echo "evil command" >> ~/.bashrc
bash: /home/alice/.bashrc: Read-only file system

Managing Drop environments

Drop environments are persistent. If a process started by drop run terminates, the environment is still there and the files created by the process are kept.

For example, create a new_file within an environment webapp:

$ drop run -e webapp bash -c 'echo hello > ~/new_file'

A subsequent drop run within the same environment still sees the created file:

$ drop run -e webapp cat ~/new_file
hello

drop ls lists all the created environments; drop rm removes an environment and all its files.

With Drop environments you don’t need to track what files and dirs programs create in your home dir. Each environment has its own home dir, which is removed together with the environment.

Other commands

  • drop help - prints usage and available commands
  • drop COMMAND help - prints command-specific help, lists options supported by the command
  • drop update --check - checks if a new version of Drop is available

Sharing the project directory

When you work on a project, you usually want convenient access to the project files to edit them, review changes, commit and push. You may also prefer for the project files to be stored within your normal home directory tree, not in the Drop environment dirs.

To help with this, drop init configures the created environment to have read-write access to the directory in which drop init was run, except for its .git subdirectory, which is read-only. This is done only if the current working directory is not your home dir or a parent of it, to avoid exposing the whole home dir to the sandbox.

A sandboxed program can modify any file it has write access to, so don’t run such scripts, Makefiles, tests or binaries outside the sandbox.

If you don’t want to expose the current directory to the created environment, pass the --no-cwd flag:

drop init --no-cwd

At any time you can also edit the TOML config generated by drop init to add or remove exposed directories.