CorpseFinder false positives for encrypted secondary user profiles

[d4rken]

Spin off ticket from #44

Affects SD Maid v0.6.0+
Running the CorpseFinder with root on a device with multiple user profiles can yield false positives after a fresh boot.

If SD Maid is run from the primary user account, and a secondary user-account exists, it's possible that the secondary user credentials have not been entered yet, so the secondary storage is still encrypted and the filenames too.

So instead of
/data_mirror/data_ce/null/10/com.topjohnwu.magisk
we get something like
/data_mirror/data_ce/null/10/H3C2fAAAAAAVlFnADbp8tqbxVFSnoLNJjInBGpx7RqqpgU9YKhP+0A

eu.darken.sdmse_logfile_1680699762427.log.zip

Originally posted by @djocqer in #44 (comment)

[d4rken]

https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/jni/com_android_internal_os_Zygote.cpp;l=1218?q=symbol:PreApplicationInit

/**
 * Hide the CE and DE data directories of non-related apps.
 *
 * Without this, apps can detect if any app is installed by trying to "touch" the app's CE
 * or DE data directory, e.g. /data/data/com.whatsapp.  This fails with EACCES if the app
 * is installed, or ENOENT if it's not.  Traditional file permissions or SELinux can only
 * block accessing those directories but can't fix fingerprinting like this.
 *
 * Instead, we hide non-related apps' data directories from the filesystem entirely by
 * mounting tmpfs instances over their parent directories and bind-mounting in just the
 * needed app data directories.  This is done in a private mount namespace.
 *
 * Steps:
 * (1) Collect a list of all related apps (apps with same uid and allowlisted apps) data info
 *     (package name, data stored volume uuid, and inode number of its CE data directory)
 * (2) Mount tmpfs on /data/data and /data/user{,_de}, and on /mnt/expand/$volume/user{,_de}
 *     for all adoptable storage volumes.  This hides all app data directories.
 * (3) For each related app, create stubs for its data directories in the relevant tmpfs
 *     instances, then bind mount in the actual directories from /data_mirror.  This works
 *     for both the CE and DE directories.  DE storage is always unlocked, whereas the
 *     app's CE directory can be found via inode number if CE storage is locked.
 *
 * Example assuming user 0, app "com.android.foo", no shared uid, and no adoptable storage:
 * (1) Info = ["com.android.foo", "null" (volume uuid "null"=default), "123456" (inode number)]
 * (2) Mount tmpfs on /data/data, /data/user, and /data/user_de.
 * (3) For DE storage, create a directory /data/user_de/0/com.android.foo and bind mount
 *     /data_mirror/data_de/0/com.android.foo onto it.
 * (4) Do similar for CE storage.  But if the device is in direct boot mode, then CE
 *     storage will be locked, so the app's CE data directory won't exist at the usual
 *     path /data_mirror/data_ce/0/com.android.foo.  It will still exist in
 *     /data_mirror/data_ce/0, but its filename will be an unpredictable no-key name.  In
 *     this case, we use the inode number to find the right directory instead.  Note that
 *     the bind-mounted app CE data directory will remain locked.  It will be unlocked
 *     automatically if/when the user's CE storage is unlocked, since adding an encryption
 *     key takes effect on a whole filesystem instance including all its mounts.
 */