idea: limiting permissions

Numerous people suggested interesting ideas how maybe permissions could be dropped when running in "unsafe" mode, i.e. when the subprocess is re-spawned with every key which modifies the edited command. What follows is the list of approaches which might work to implement this idea, in random order, with annotations:

• ❌ run subprocess as "nobody" user → this can access other programs running as nobody; also to do this, increased permissions are required (i.e. root) — I don't want to go this way
  • https://unix.stackexchange.com/questions/186568/what-is-nobody-user-and-group#186581
  • "drop user permissions" — the same IIUC
• ❌ man capabilities → Linux is able to grant some (partial) root permissions, not to drop some regular user permissions (like writing files). An unprivileged user doesn't have any capabilities that we could drop.
• ❔ "namespaces" → see containers
• ❌ "unshare [syscall?]" → it's apparently possible, but I believe it would only affect the top-level bash, not all the child processes in the actual pipeline... :/
• ❔ firejail
• ❔ overlayFS
• ❔ limiting syscalls ("whitelist/blacklisting sys_unlink") → see seccomp
• ❌ "start subprocess in a container" (via) → for now it seems much too complicated and heavyweight for me for up; up is a small program, I don't see this as a good fit. Also, containers actually are not exactly advised for security. Anyway, see above "namespaces" and "overlayFS", etc. Also, you need to be root to setup a container/namespace.
• ❌ LD_PRELOAD → IIUC, this wouldn't trap programs which don't use libc, e.g. any Go program
• ❔ "seccomp" (via) → This is usually used for sandboxing to whitelist syscalls, but can be used to reject certain syscalls or reject a syscall if certain flags are set. This could be used to setup a sandbox that rejects all syscalls that modify the filesystem. Note that this is not intercepting syscalls with ptrace but rather loading a filter into the kernel. This doesn't require root privileges like many of the other solutions.

Discussion, Counterarguments

Not all dangerous or undesirable actions necessarily involve modifying the file system -- and I might very well want to execute a command that modifies the file system. (via)