Open hadess opened 7 years ago
If we now have 3 glib-C projects using bwrap it might make sense to have a little copy-paste libgbwrap or something.
That looks just about what we'd need. But for my use, as a prelude to debugging, a command-line argument to bwrap would be enough, such as bwrap --self-test
and output any errors.
https://github.com/projectatomic/bubblewrap/issues/217 is related to this.
I don't understand how it's related. The problem is that we either need the kernel allowing user namespaces creation for normal users (as is done in Fedora), or bwrap being suid (which is how it's done in Debian and derivatives).
When self-building bubblewrap, it's possible to end up with neither being true. The self test would be a way to avoid contrived debugging of the upper-layers that use bwrap when the system itself doesn't allow us to do anything worthwhile.
For a self-test, we need to know what arguments to pass to get enough of a valid root filesystem to run even /usr/bin/true
or something like that (at least on Fedora userspace it's dynamically linked).
See https://git.gnome.org/browse/gnome-desktop/commit/?id=886994f2282a317848714a19e08f4fa63adc1bac for example.
Right, fair enough.
bwrap --ro-bind / / true
is a nearly universal self-test.
It is currently possible to have bwrap installed correctly, but completely broken because neither of the 2 options that would allow bwrap to work are enabled.
In https://bugzilla.gnome.org/show_bug.cgi?id=787249 the user installed bwrap with suid mode disabled (I'm guessing the default) and userns disabled in the kernel.
A self-test to check whether bwrap could actually be launched would be useful.