Repository navigation
[FEATURE?]Is /mnt/Droidspaces visibility in host mountinfo expected? #306
Description
Activity
On Droidspaces v6.5.0 with KernelSU, a regular app without root access can read
/proc/self/mountinfoand see entries such as: /mnt/Droidspaces/ ... /dev/block/loop... This exposes a detectable Droidspaces/root-related artifact to apps performing root checks. Is this visibility expected, or should the image mount exist only inside the container’s private mount namespace?yes, this is expected. You can see /mnt/Droidspaces/ as we have to mount the rootfs.img somewhere in the Android side just to boot into it.
The stuffs that's mounted inside the container's isolated private mount namespace is not visible to the Android at all.
Thank you for the clarification! I understand that the Android-side mount is currently required to boot the rootfs.img.
With the container running, I observed that both Momo (io.github.vvb2060.mahoshojo) and Native Test (com.android.nativetest) reported “su process detected”. I cannot confirm that the Droidspaces mount is the direct cause, so this may require further investigation, but the visible mount appears to be a possible root-detection signal.
Would it be technically possible to isolate or hide /mnt/Droidspaces/ from ordinary Android apps while preserving normal container functionality? Just floating an idea here—not sure if it's feasible or worth the complexity, but figured it might be helpful to mention!
Thank you for the clarification! I understand that the Android-side mount is currently required to boot the rootfs.img.
With the container running, I observed that both Momo (io.github.vvb2060.mahoshojo) and Native Test (com.android.nativetest) reported “su process detected”. I cannot confirm that the Droidspaces mount is the direct cause, so this may require further investigation, but the visible mount appears to be a possible root-detection signal.
Would it be technically possible to isolate or hide /mnt/Droidspaces/ from ordinary Android apps while preserving normal container functionality? Just floating an idea here—not sure if it's feasible or worth the complexity, but figured it might be helpful to mention!
Doing this eliminates the ability to manually edit the files inside a rootfs.img via navigating into /mnt/Droidspaces using a root explorer... So, this is not feasible.. :(
I'd prefer keeping the current behavior rather than fixing a root detector.
Ah, that makes sense! In that case, would it be possible to unmount the path specifically for apps included in the KernelSU / Zygisk Next deny list (exclusion list)?
This way, root explorers could still access the directory normally, while target apps wouldn't be able to see the mount point.
Thanks for the explanation! I have no further questions.
Ah, that makes sense! In that case, would it be possible to unmount the path specifically for apps included in the KernelSU / Zygisk Next deny list (exclusion list)?
This way, root explorers could still access the directory normally, while target apps wouldn't be able to see the mount point.
Thanks for the explanation! I have no further questions.
Yes, I saw people doing a similar approach with susfs..
On Droidspaces v6.5.0 with KernelSU, a regular app without root access can read
/proc/self/mountinfoand see entries such as: /mnt/Droidspaces/ ... /dev/block/loop...This exposes a detectable Droidspaces/root-related artifact to apps performing root checks.
Is this visibility expected, or should the image mount exist only inside the container’s private mount namespace?