containers / bubblewrap

Low-level unprivileged sandboxing tool used by Flatpak and similar projects
Other
3.97k stars 237 forks source link

kill background processes on exit #105

Open joshmyzie2 opened 8 years ago

joshmyzie2 commented 8 years ago

I run an application using bubblewrap that forks off a number of background processes. When closing the application, the background processes are not always cleaned up, so if I run lsns, I will still see bwrap running and the background processes as its children. To clean up the namespace, I have to send the KILL signal to bwrap.

Is it possible for bwrap to automatically kill everything in the namespace when the foreground process terminates? Or is there a reason why that wouldn't be appropriate?

BTW, bubblewrap is awesome; thanks for writing it!

joshmyzie2 commented 8 years ago

This workaround seems to do what I wanted:

cmd="bwrap ..."
setsid sh -c "$cmd; kill -s KILL -- -\$\$"

Feels free to close this ticket if it doesn't make sense to add this to bubblewrap.

alexlarsson commented 8 years ago

The origin of the bwrap code comes from flatpak, which doesn't need this feature (because in general you don't know if the "main" process is the app or if it forks one. However, technically there is no reason you could not implement this feature.

In particular, if you use --unshare-pid then every process of the sandbox is guaranteed by the kernel to die when pid 1 in the sandbox dies. The pid1 code already detects when the initial process dies and could easilty be made to optionally die at that point.

cgwalters commented 7 years ago

I think we should also add --bind-lifecycle-parent which does PR_SET_PDEATHSIG in the init process. That would be convenient for test suites, then you can do e.g. bwrap --blah inside a make check suite, and you'd be guaranteed the test containers die when make does.

cgwalters commented 7 years ago

Otherwise, yeah, using --unshare-pid should suffice for this? In the latest version we'd recommend --unshare-all.

cgwalters commented 7 years ago

I took a quick stab at using PDEATHSIG but it doesn't appear to work with a pid namespace. We'd need an "outer init" process outside the namespace.