[Discussion] Idea about working Modules + Whitelist mode / Alternatives to Whitelist mode

This thread is only about discussing about ideas to have modules working with white list mode

The first idea that came is to whitelist by default some system apps modules apps and required system services required to make apk from custom modules work

Examples of whitelisted by default packages

com.android.systemui
com.android.settings
com.android.shell <= ADB Root 
com.android.webview <= Only required to fix webview on somes ROM (if ro.build.tags = release-keys theses package won't be whitelisted by default)
com.google.android.webview <= *same*
com.android.chrome <= *same*

The second idea is instead of making all apps hidden by default we don't put already installed apps in the hide list but we listen to every package installation and we add new apps to the hide list until the user removes the apps to the hide list or the user click on Remove from hidelist on the notification (if enable) that MagiskManager will send Since magisk daemon already listen to package install and need to communicate with MagiskManager it will be also useful to restore the Reauthetificate after upgrade functionality on android 8.0+

The third idea is more complex and will not work on every device on the first try but is more powerful The problem with modules is that we require mount point to achieve systemless system modification that means MagiskHide need to remove those custom mount points to hide from app that make all system modification revert to normal but that also make themes no longer work

The idea is to create a custom "kernel module" to emulate a legitimate system mount but instead to be managed by the original system driver it will be managed by the custom magisk filesystem driver that can change systemlessly sytem files without creating custom mount that triggers most of app magisk checks

This will allow themes to work with magisk hide enabled on the app at the same time

But the big problem with this idea is that can be very unstable and will not work on every device and also it will take too much time to make everything work properly

I think the best idea is the second idea because I think is the more stable idea but also because it will not break the modules so much.

I wanted to propose alls my idea I have in mind to discuss about them

By whitelist mode when I mentioned it in Twitter, I mean NOTHING will be mounted by default, and ONLY those that are on the whitelist will be given an environment with Magisk included. So apparently this will not work with modules, because the whole point of modules is to mount files and change the behavior of the system. If we don't mount anything by default, there is absolutely no concept of "module".

What you are proposing here is based on the current hide implementation, and change the default targets. You should figure out by now that this is a completely different subject from what I meant about "whitelist" mode. Since it is later found out that the new detection method we found internally will not work on normals apps, the necessity of my "whitelist mode" is no longer valid. Regarding this, the first and third idea is not relevant to the discussion.

The second idea you proposed is actually a good feature to add into Magisk, however it is very difficult to achieve in practice. Starting from Android 8.0, the system no longer send broadcasts for app installation/upgrade events. Although the daemon does indeed monitor /data/system/packages.xml for any change event, we do not know which package is modified: the reason for monitoring packages.xml is to simply reconstruct our UID <-> package name mapping that is maintained internally, and NOT to know which packages are added/modified. Also, technically speaking, Magisk does not target "packages", but instead targeting "processes". It is possible for an app to upgrade itself with a new component that spawns a new process, in order to detect that is very computational heavy and not feasible in any sense.

topjohnwu / Magisk

[Discussion] Idea about working Modules + Whitelist mode / Alternatives to Whitelist mode #1703