Unable to run even though I appear to have all relevant features except CONFIG_USER_NS about bubblewrap HOT 22 OPEN

Do you have CONFIG_USER_NS=y ? Note that flatpak uses --unshare-user-try; it's possible that something is going wrong there.

It looks like in this code path we do a stat ("/proc/self/ns/user", &sbuf) == 0...but from a quick look at the kernel source it seems that shouldn't exist if CONFIG_USER_NS=n...does it exist on your system?

from bubblewrap.

This configuration I think hasn't been tested much - both RHEL7 and Debian stable do have CONFIG_USER_NS=y, except they have out-of-tree patches to restrict it, hence the custom code to deal with it. I don't think any of the bwrap authors have tested on CONFIG_USER_NS=n systems.

(But it totally makes sense for it to work, so let's debug it)

from bubblewrap.

Arch has user ns fully disabled, and flatpak works fine there.

from bubblewrap.

@cgwalters CONFIG_USER_NS doesn't exist either "y" or "n".

from bubblewrap.

@cgwalters The items that exist under /proc/self/ns are:

• ipc
• mnt
• net
• pid
• uts

from bubblewrap.

If you are on arch, you can use the linux-grsec kernel (a good idea in general)
It has (restricted) user namespaces enabled and works fine with bubblewrap

from bubblewrap.

In reply to sonicou, no, this is a Debian-derived Linux. Thanks for the idea, though.

from bubblewrap.

Maybe there is an "strace" command line I can run to help troubleshoot this?

from bubblewrap.

Does bwrap --bind / / true work, or does it give the same error?
If it fails, you can try sudo strace -u $USER -o bwrap.log -f bwrap --bind / / true, and look at bwrap.log.
If it doesn't fail, try adding switches until it does.

from bubblewrap.

bwrap --bind / / true runs successfully (0 exit status; if I substitute true by false, I get an exit status of 1 as expected).

To follow your next bit of advice, "If it doesn't fail, try adding switches until it does," I had to find out what switches were being passed to bwrap. My results were a bit unusual; I'll give some details because this involves flatpak, which isn't your project.

In the source tree (*) of the app I'm trying to install in Flatpak, I tried strace on the script (**) that calls a Python script (in the same source tree) that calls the flatpak binary.

* By my reading of the app's Download webpage, source code is the way to install my app, since my distro predates the repos (listed on http://flatpak.org/getting.html) from which I could download Flatpak.
** This is the script I had originally been trying to run that prompted my filing this GitHub issue.

The closest the strace output got to giving me bwrap parameters was
execve("/usr/local/libexec/flatpak-bwrap...

So I renamed /usr/local/libexec/flatpak-bwrap to /usr/local/libexec/flatpak-bwrap-real and added a shell script called /usr/local/libexec/flatpak-bwrap whose line of code looks like:

strace -ve trace=process -s 1024 -o /home/dg1727/install/strace -ff /usr/local/libexec/flatpak-bwrap-real "$@"

When I ran the app script with my flatpak-bwrap shell script in place, the Creating new namespace failed message was still printed to the terminal window as when I filed this issue.

In the ensuing strace output, again the closest I found to bwrap parameters was
execve("/usr/local/libexec/flatpak-bwrap-real",... and about 12 kilobytes of string parameters. That was the first line of the strace output file.

But I also noticed that the only other lines in the strace output file were:

arch_prctl(ARCH_SET_FS, 0x7fb25f9c4700) = 0
clone(child_stack=0, flags=CLONE_NEWNS|0x38000000|SIGCHLD) = -1 EINVAL (Invalid argument)
exit_group(1)                           = ?

Is that of any help?

from bubblewrap.

Hmm, clearly one of the clone flags cause it to fail.
Can you try bwrap --unshare-net --unshare-ipc --unshare-pid --unshare-user-try --bind / / echo hi?

Oh, and btw, flatpak is my project.

from bubblewrap.

The echo hi command successfully prints hi.

Sorry for not realising that you're a Flatpak developer. No offence meant! Many thanks for chiming into this discussion/project in addition to your work on Flatpak itself.

from bubblewrap.

And if you strace that command, does it give the same clone() call arguments?

from bubblewrap.

Hmm, i see that the clone call includes CLONE_NEWUSER (0x10000000), which means either that it believes your kernel supports user namespaces, or that bubblewrap is not installed setuid, which means it always uses user namespaces (because it can't work otherwise).

Maybe your bubblewrap is installed setuid, but the flatpak is not built against the system one (--with-system-bubblewrap)?

from bubblewrap.

I can only find one bwrap on the computer, and that's the one whose source code I manually downloaded from GitHub to fill in the link in the Flatpak source tree, and compiled locally.

I ran the following:
strace -ve trace=process -s 1024 -o /home/dg1727/install/strace -ff bwrap --unshare-net --unshare-ipc --unshare-pid --unshare-user-try --bind / / echo hi

This time, it printed the Creating new namespace failed message. The clone line in the strace output was:
clone(child_stack=0, flags=CLONE_NEWNS|0x78000000|SIGCHLD) = -1 EINVAL (Invalid argument)

I then immediately ran the same command without strace:
bwrap --unshare-net --unshare-ipc --unshare-pid --unshare-user-try --bind / / echo hi
... and it successfully printed hi.

from bubblewrap.

Well, you talked about flatpak-bwrap in #139 (comment), which is the name of the bundled version of bwrap that flatpak installs unless you tell it to use the system one, and then you talk about bwrap in other comments. So, maybe there is some confusion.

Weird that the strace affected things in that way though.

from bubblewrap.

flatpak-bwrap is a binary in /usr/local/libexec/
bwrap is a binary in /usr/local/bin/
I am about 100% sure that both were installed during the same install process. All of this compiling is to get the end application to run, and neither Flatpak nor Bubblewrap was on this computer prior to that.

I noticed that flatpak-bwrap wasn't setuid. So I did: sudo chmod u+s /usr/local/libexec/flatpak-bwrap

Subsequently, as you'd expect from my previous comment, Flatpak still doesn't run with strace... but Flatpak does now run without strace. 😃

Can somewhere in the Flatpak documentation (maybe at the bottom of https://github.com/flatpak/flatpak/wiki) have a line added like:

If you build Flatpak (and its bundled version of Bubblewrap) on an OS that doesn't support user namespaces & therefore requires Bubblewrap to be setuid, you'll need to sudo chmod u+s both bwrap binaries: by default, the build process installs them as

• /usr/local/bin/bwrap
• /usr/local/libexec/flatpak-bwrap

In fact, could the build process detect whether CONFIG_USER_NS is supported and automatically setuid the binaries if CONFIG_USER_NS isn't supported? If it would be considered a security risk to setuid anything automatically, could the user be prompted that make install (or its equivalent - I don't remember the build process exactly) is about to setuid those 2 binaries? I think the Bubblewrap build would have to setuid /usr/local/bin/bwrap and the Flatpak build would have to setuid /usr/local/libexec/flatpak-bwrap

I'll be glad to pose this as a separate GitHub issue in the Flatpak project if you like (please let me know). Even if the auto-setuid would be a bad idea, I can mention it so that if someone else has the same idea later, they can find the discussion.

Thanks again!

from bubblewrap.

If you get a copy of bwrap from git submodule update, and make Flatpak compile it (./configure, etc. in the flatpak directory), then you get flatpak-bwrap and Flatpak will use that. You do not need to do a ./configure && make in the bwrap directory: Flatpak's top-level build process does the equivalent of that for you.

It sounds as though you built bwrap manually as well as letting Flatpak build it, which is why you have two copies installed. You don't need to do that.

Building bwrap manually is only necessary if you are going to tell Flatpak's build process --with-system-bubblewrap=bwrap or something. If you do that, Flatpak won't compile its own flatpak-bwrap, and it will run bwrap instead. That's what distributions like Debian do (we don't like using bundled copies of things that are also available as a separate project).

If you are running a Debian derivative, you can get up-to-date Flatpak and Bubblewrap source packages from Debian unstable.

could the user be prompted

No. make install has to be non-interactive.

from bubblewrap.

Thanks for that clarification.

I've opened issue flatpak/flatpak#503 and pull request flatpak/flatpak#504 so that hopefully, building Flatpak from source will go more smoothly.

I'm thinking of re-downloading the Flatpak source using git clone --recursive and verifying that, after chmod u+s /usr/local/libexec/flatpak-bwrap, Flatpak runs OK. At that point, I'll likely close this issue.

I was sure enough of Flatpak items 503 & 504 that I submitted them right away; I then wanted to update everyone on the status of this bwrap issue.

from bubblewrap.

Gah! This is so confusing! I to am getting the namespace issue. If there's a bullet list of instructions for an idiot like me, that'd be amazing.

I'm installing on WSL Ubuntu 18.04

from bubblewrap.

on WSL

Flatpak and bubblewrap require Linux. WSL is not Linux, it's Windows pretending to be Linux, and it does not have the full feature-set of a modern Linux kernel. As far as I am aware, it doesn't implement namespaces, so you are out of luck.

from bubblewrap.

does this wsl update bring what flatpak needs?
microsoft/WSL#2017

from bubblewrap.