Unable to run even though I appear to have all relevant features except CONFIG_USER_NS

[dg1727]

Hi,

I'm trying to install a Flatpak app on a distro which predates Flatpak support.

Error message:

Creating new namespace failed, likely because the kernel does not support user namespaces. bwrap must be installed setuid on such systems.

The kernel has got the following:
CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_DEVPTS_MULTIPLE_INSTANCES=y CONFIG_OVERLAYFS_FS=m (There may be a spelling error in CONFIG_OVERLAYFS_FS in issue #87.)

-rwsr-xr-x 1 root root 164080 Jan 6 04:55 /usr/local/bin/bwrap*

Version is bubblewrap 0.1.5.

Any suggestions?

[cgwalters]

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?

[cgwalters]

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)

[alexlarsson]

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

[dg1727]

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

[dg1727]

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

• ipc
• mnt
• net
• pid
• uts

[sonicou]

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

[dg1727]

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

[dg1727]

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

[alexlarsson]

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.

[dg1727]

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?

[alexlarsson]

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.

[dg1727]

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.

[alexlarsson]

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

[alexlarsson]

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)?

[dg1727]

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.

[alexlarsson]

Well, you talked about flatpak-bwrap in https://github.com/projectatomic/bubblewrap/issues/139#issuecomment-273553371, 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.

[dg1727]

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. :smiley:

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!

[smcv]

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.

[dg1727]

Thanks for that clarification.

I've opened issue https://github.com/flatpak/flatpak/issues/503 and pull request https://github.com/flatpak/flatpak/pull/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.

[drbree82]

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

[smcv]

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.

[mailinglists35]

does this wsl update bring what flatpak needs? https://github.com/Microsoft/WSL/issues/2017