[Bug/Question] Cannot create User Namespace inside container, causing Flatpak / bwrap to fail

[OneFeiFan]

Hi,
​I found that Flatpak applications cannot run properly inside Droidspaces containers. After some initial troubleshooting, the root cause appears to be that bwrap (bubblewrap) fails to work due to permission issues.
​To pinpoint the problem, I ran some comparative tests using the unshare command:

PID Namespace works fine:

unshare --pid --fork echo "✅ PID Namespace is supported!"
The above command executes successfully.

User Namespace fails to create:

unshare --user echo "✅ User Namespace is supported!"
The above command fails, unable to create a user namespace.

Additional Context:

My device's kernel has CONFIG_USER_NS=y enabled. Furthermore, the exact same unshare --user test command works perfectly fine in Termux.

Question:

I would like to ask if this is an intentional restriction designed by Droidspaces for security reasons (e.g., the default Seccomp profile blocking CLONE_NEWUSER), or is it a bug?
​If it is an intentional security limitation, is there an option or workaround provided to override/modify the Seccomp rules or grant the necessary privileges, so that tools relying on User Namespaces (like Flatpak) can work properly?

[ravindu644]

Hey, this is intentional.

We block the creation of user namespace via seccomp for security..

[ravindu644]

Droidspaces-OSS/src/seccomp.c

Line 84 in a998b75

/* unshare(CLONE_NEWUSER) - a new user namespace grants a full capability

[ravindu644]

However, i agree that supporting flatpak and bubblewrap is a legitimate use case that warrants an exception.

i am happy to implement this as an optional feature. the goal is to introduce a new command line flag:
--allow-user-ns

for the android app, we can add a corresponding toggle under the security and boot section so users can enable it per container.

i am currently focusing on exams and other core priorities, so i will not be able to implement this immediately. if you or anyone else would like to see this move faster, i would be happy to review a pull request.

implementation pointers:

1. seccomp: the primary change is adding a conditional check to the user ns seccomp block in seccomp.c.
2. documentation: if you submit a pr, please make sure to update documentation.c and the relevant md files. since this is a new feature that affects the security model, we need to ensure it is well documented for other users.

looking forward to your contribution.

[OneFeiFan]

After spending some time tinkering, I finally managed to enable User Namespace permissions within the container, successfully getting Flatpak up and running. However, due to my limited understanding of the underlying Android and Linux security mechanisms, my modifications were somewhat brute-force. The code style might not be optimal, and these changes are highly likely to be unsafe or introduce breaking behaviors.
​While it is operational for now, there are still quite a few limitations. I would like to highlight two major issues I've observed:
​First is the issue with nested sandboxing. In the current Flatpak environment, attempting to launch any internal sandbox will cause the application to crash immediately. Therefore, for applications relying on Zypak, it is highly recommended to call the main executable directly to bypass Zypak's environment checks. For other applications that enable sandboxing by default (such as Electron-based apps), appending the --no-sandbox flag is absolutely necessary for them to run properly.
​Second is the GPU limitation. Certain applications that heavily rely on hardware GPU acceleration will fail to launch. To render the interface correctly, these apps must be forced into pure software rendering mode (e.g., by explicitly disabling GPU acceleration).

[ravindu644]

After spending some time tinkering, I finally managed to enable User Namespace permissions within the container, successfully getting Flatpak up and running. However, due to my limited understanding of the underlying Android and Linux security mechanisms, my modifications were somewhat brute-force. The code style might not be optimal, and these changes are highly likely to be unsafe or introduce breaking behaviors.​While it is operational for now, there are still quite a few limitations. I would like to highlight two major issues I've observed:​First is the issue with nested sandboxing. In the current Flatpak environment, attempting to launch any internal sandbox will cause the application to crash immediately. Therefore, for applications relying on Zypak, it is highly recommended to call the main executable directly to bypass Zypak's environment checks. For other applications that enable sandboxing by default (such as Electron-based apps), appending the --no-sandbox flag is absolutely necessary for them to run properly.​Second is the GPU limitation. Certain applications that heavily rely on hardware GPU acceleration will fail to launch. To render the interface correctly, these apps must be forced into pure software rendering mode (e.g., by explicitly disabling GPU acceleration).

Oh, okay. We'll figure out the remaining issues regarding what's going on when using sandboxing. I'll also work on this feature in my free time. After adjusting the code to cover the edge cases, I'll merge the PR.

[ravindu644]

After spending an intense amount of time, I still cannot get bwrap working in my kernel:

root@debian:~# flatpak run org.gnome.Calculator
bwrap: Can't mount proc on /newroot/proc: Device or resource busy

Also, to make bwrap/flatpak even partially work, we had to completely nuke the /proc masking, which leads to container processes modifying the host's kernel parameters, specifically those related to BPF. This makes the host soft-panic if the user namespace option is enabled.

I confirmed that user namespaces themselves are working; it is just bwrap that is not working.

So, we either have to add a warning about this or completely remove the feature from the repo, as our intention of "Running flatpak/bwrap" does not work.

Maybe this is an issue with my kernel; it is quite old (4.14.356).

If the same issue happens for more people, this toggle creates disadvantages in security rather than adding a new feature.

I am so sorry for your time. I never thought this would happen :(

[OneFeiFan]

Regarding the discrepancy in our test results, I would like to provide my device environment for your reference:
I am using a Xiaomi Pad 6 Max (Snapdragon 8+ Gen 1) running Android 15. The most critical point is that my kernel version is 5.10.246-android12. This is a GKI kernel I custom-compiled previously specifically to run LXC and Docker, during which I manually enabled a large number of kernel options related to containers and namespaces.

Therefore, I am not entirely sure if bwrap works on my device because the 5.10 kernel is newer, or because those specific kernel options I enabled caused the environmental difference between us.

In fact, before I modified the /proc mounting logic in Droidspaces, my bwrap was not working properly either. The specific behavior was:
When running bwrap --ro-bind / / --dev /dev --proc /proc --unshare-all --uid 1000 --gid 1000 echo "✅ Bwrap is fully functional!",
it would throw an error directly: bwrap: Can't mount proc on /newroot/proc: Operation not permitted.

If --proc /proc is replaced with --bind /proc /proc, the command does execute, but this provides no actual help for running Flatpak or sandbox isolation.

Here, I have attached screenshots of my current kernel's LXC/Docker compatibility check, as well as a screenshot of Flatpak running successfully for your reference:

I completely agree with your point: if bwrap indeed cannot run on the kernels of most standard devices, and lifting the restrictions allows host kernel parameters to be tampered with, then merging these backend modifications is truly not worth the cost. Introducing a feature that does more harm than good and carries severe security risks goes against the project's original intention.

To ensure the stability and security of Droidspaces, please feel free to revert or discard this PR. I completely understand, and I will keep these destructive modifications in my personal branch for my own use. Thank you so much for investing your valuable time in testing!

[ravindu644]

Hey, it's okay.

Maybe this is a kernel issue. I have a 5.15.167 device as well - I'll check it there 😊

For some reason,

unshare --user --map-root-user --mount-proc --fork --pid /bin/bash works as expected, even getting a fresh /proc mounted.

It's just Flatpak that cannot mount /proc inside its namespace.

I don't know who's to blame 😅

Usually, even with /proc masking, the kernel allows us to mount a new instance of /proc somewhere inside. It's how the kernel works.

I don't know what's going on with Flatpak and why it requires absolutely no bind mounts on top of the host's /proc.

I'll tell you the results once I have tested these with my other phones.

Well, we don't need to nuke this option entirely. We can either move this feature to another branch or keep it as it is with tightened warnings.

If someone later figures out how to fix this issue, they can make a contribution to the repository.

Thank you for your contribution.

[ravindu644]

I have moved your changes to a separated branch for now:

https://github.com/ravindu644/Droidspaces-OSS/tree/user-ns-test

anyone can contribute to that branch to fix remaining issues related to flatpak/bwrap :)