found 2 hidden bugs that were unnoticed for months. fixing them right now💀

1. https://t.me/DroidspacesDiscussion/4279
2. https://t.me/DroidspacesDiscussion/4257

Droidspaces v5.8.1

https://github.com/ravindu644/Droidspaces-OSS/releases/tag/v5.8.1

Fixes:

- fix(runtime): prevent metadata overwrite during container scan
- fix: restrict Termux X11 conflict check to 'start' or 'restart' commands
- fix: skip Termux force-stop if unified /tmp bridge is already mounted

@Droidspaces

Well,

Developers can now integrate the droidspaces daemon at the init.rc level.

Theoretically, you can run droidspaces without root if it is integrated into the Android init system.

However, since it is dangerous, I have artificially limited the ability for non-root users on Android to connect with the droidspaces socket.

On Linux, though, users can run droidspaces commands without sudo!

For Magisk/APatch issues, enabling the toggle is enough.

For GrapheneOS users, however, they might need to integrate droidspaces as an init service to fix certain syscalls that get blocked even when running as root.

testing :)

1. Install
2. Enable daemon mode
3. Reboot the device
4. Tell me the results :)

here's the test APK:

1. Install
2. Enable daemon mode
3. Reboot the device

This APK should fix:

1. All the issues related to Magisk/APatch
2. rootfs.img mounting issues in all devices

Currently, the daemon drops all connections from non-UID0 sockets for security. That means to communicate with the daemon, you must be root, even though theoretically root isn’t required for a client.

This design choice is intended to block malicious connections from managing or running arbitrary commands inside containers as malicious processes.

If your rooting method is compromised, droidspaces, along with all your modules and everything else under the sun, will be compromised too.

Since the daemon uses an abstract socket called @droidspaces, all apps are denied by SELinux anyway, even if I remove the checks. There’s no fix for that without patching SELinux to allow the "untrusted apps" domain to communicate with the socket. But:

We can’t allow untrusted apps to communicate with the daemon via SELinux either. Why? Because that would let any userspace app communicate with the droidspaces app and potentially with any socket in the system, which is extremely dangerous.

The daemon and client are baked into the same droidspaces binary. Also, the binary can directly execute commands if no daemon is found AND it has root. A 3-in-1 solution.

The app requires root anyway to install containers, etc., so even without strict UID checks, the app will partially work.

We can’t use droidspaces as a “command execution environment” for non-root processes to execute root commands needed for the app either. If a vulnerability in droidspaces is exploited, any non-root process could spawn a root shell.

The biggest concern is that the droidspaces binary can execute commands directly inside running containers using the run command. If any process could connect to the socket, it could enter container shells, execute commands, nuke containers, plant backdoors, etc.

This is a massive security risk.

So, until someone implements a kernelsu-like solution to “crown” the official droidspaces manager and block connections from everything else, I won’t implement such a feature.

Even if I did, it would overcomplicate the app’s code. Thanks to our 3-in-1 architecture, I didn’t have to touch any app code; the droidspaces binary acts as a client for the daemon if it detects the socket is alive.