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.

Well,

If you really wanted to run a container without root,

You can get help from the upcoming run-at-boot feature baked into the init.

Then,

You can ssh into the container IP if it's NAT or localhost:22 to get a container shell.

This is the secure way of accessing the container without root.

For clarification, Droidspaces supports two daemon modes:

1. Run the daemon via Magisk/Apatch/KernelSU modules' native post-fs-data.sh. By enabling the toggle in the app, you activate the logic in the post-fs-data.sh of the Droidspaces Magisk module to run the daemon on boot.

For 99% of users, this solves all issues with Magisk and Apatch. No modifications to your vendor.img are needed.

2. Run the daemon via Android's native init.rc:

- This mode is the most privileged and completely independent of Magisk/Apatch/KernelSU. It even works without any root solutions.
- The daemon is unkillable. If something kills it, init will automatically respawn it.
- Run-at-boot containers are unkillable as well. If droidspacesd gets killed, once init restarts it, run-at-boot will also restart all killed containers.

I don't think Android will ever kill the daemon, but even if it does, all edge cases are covered—thanks to my overthinking 🗿

Notes: If the native init daemon is enabled, the app's toggle will be automatically enabled. The post-fs-data.sh script will auto-detect if the native init.rc daemon is running, so no collisions will happen if it is.

Everything is backward compatible. You don't even need to worry about daemons if everything is already working for you 🗿

Nothing bad will happen; the binary still supports running everything natively, with or without a daemon 🗣

There are three different logics baked into the same binary:

- Daemon
- Client for the daemon
- Native execution if no daemon is running