smcv
commented
1 month ago No, there is not.
If you're doing what bubblewrap does (putting a child process in a sandbox), there's really no way to avoid having a child process: even if bubblewrap itself didn't need to be a child process, the sandboxed process would. You can't have half of your process be in one namespace and the other half be in another, that's just not possible.
If it's acceptable for your program to only work on systems that have access to unprivileged user namespaces, then you can do all the same things that bubblewrap does, from your own library code, if you want to: there's nothing magic about it. (For example, I think Chromium uses the same syscalls that bubblewrap does.)
On systems where the only reason that bubblewrap can do its job is by being setuid root, there is no way to get equivalent functionality from a library: your only option is to run the setuid binary as a child process, because only a setuid binary has the necessary privileges to be able to do bubblewrap's job.
Larger frameworks that run bubblewrap (such as Flatpak) generally have some utility code to construct a list of bubblewrap arguments: for example Flatpak's FlatpakBwrap and FlatpakExports would be a good starting point. There has been a vague idea for a while that "someone" should write a libbubblewrap to help with this, but none of the maintainers of bubblewrap have yet had the time available to do so.
It would be great if there would be like a shared library for creating the sandbox. Otherwise i would have to spawn a child process for interacting with this software.