nix-appimage icon indicating copy to clipboard operation
nix-appimage copied to clipboard

Fails for applications that use user namespaces

Open BentonEdmondson opened this issue 4 months ago • 3 comments

My native unshare works:

$ unshare -U echo hi
hi
$ echo $?
0

But the AppImage doesn't:

$ ./bundle util-linux /bin/unshare
$ ./unshare-x86_64.AppImage -U echo hi
unshare-x86_64.AppImage: unshare failed: Operation not permitted
$ echo $?
1

I believe this is the reason Steam, Chromium, and Electron apps don't work:

$ ./steam-x86_64.AppImage
bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'.

$ ./ungoogled-chromium-122.0.6261.69-x86_64.AppImage
[52161:52161:0226/172919.336302:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /nix/store/zamhhinmqjvvxj1ipfijvrpqs85q3rc0-ungoogled-chromium-122.0.6261.69-sandbox/bin/__chromium-suid-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap (core dumped)

$ ./bitwarden-2024.2.0-x86_64.AppImage
[60941:0226/173049.236563:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /nix/store/9zw7gk36f07lnn6y60ksd2s063q46ri1-electron-28.2.2/libexec/electron/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap (core dumped)

This article suggests that this is not a fundamental limitation of the AppImage format; assuming unprivileged user namespaces are enabled in the kernel, Electron AppImages can be run without disabling their sandbox.

BentonEdmondson avatar Feb 27 '24 00:02 BentonEdmondson

nix-appimage uses unprivileged user namespaces itself -- it works by copying all required nix store files into the AppImage, then "mounting" them at /nix/store. I don't see any other way of doing that without user namespaces.

I'm guessing that you're getting these errors because Linux doesn't allow nested user namespaces? If that's the case I'm leaning towards marking this as WONTFIX, sorry :(

ralismark avatar Feb 27 '24 14:02 ralismark

No, nesting user namespaces is possible:

$ unshare -c unshare -U echo hi
hi

I looked at it more closely and I found the problem. The man page says you can't create a user namespace within a chroot:

  EPERM (since Linux 3.9)
         CLONE_NEWUSER was specified in flags and the caller is in
         a chroot environment (i.e., the caller's root directory
         does not match the root directory of the mount namespace
         in which it resides).

You chroot right here: https://github.com/ralismark/nix-appimage/blob/17dd6001ec228ea0b8505d6904fc5796d3de5012/apprun.c#L188-L198

When I remove those lines the problem seems to be completely fixed. What is the reason for the chroot?

BentonEdmondson avatar Feb 28 '24 00:02 BentonEdmondson

i need chroot in order to mount the bundled /nix/store. on systems without nix, I'm pretty sure i need there to already be a /nix directory in order to mount, and since i can't make that directory, i need to make a copy of / with the extra directory and chroot

ralismark avatar Feb 28 '24 13:02 ralismark