The utils function may be called in any situation, such as in daemon. We
should guarantee that all the resource got from this function released
normally.
Signed-off-by: yuchenlin <npes87184@gmail.com>
Introduce a new communication method between Magisk and Magisk Manager.
Magisk used to hardcode classnames and send broadcast/start activities to
specific components. This new method makes no assumption of any class names,
so Magisk Manager can easily be fully obfuscated.
In addition, the new method connects Magisk and Magisk Manager with random
abstract Linux sockets instead of socket files in filesystems, bypassing
file system complexities (selinux, permissions and such)
Boot services tend to fail in the middle when the kernel loads a sepolicy live.
It seems that moving full patch (allow magisk * * *) to late_start is still not enough to fix service startup failures.
So screw it, apply all patched in magiskinit, which makes sure that all rules are only loaded in a single step.
The only down side is that some OEM with a HUGE set of secontexts (e.g. Samsung) might suffer a slightly longer boot time, which IS the reason why the rules are split to 2 parts in the first place.
In previous versions, magiskinit will not early mount if /sepolicy is detected. However on OP5/5T latest betas, the devices are fully trebelized,
but for some reason the file /sepolicy still exists, making magiskinit think it is NOT a treble device and doesn't work properly.
So to properly fix this issue, I will have to use the "official" way - check fstab in device trees. Any block mentioned in the fstab in device trees
are supposed to be early mounted. Currently magiskinit will only mount system and vendor even if other partitions exists in the dtb fstab, since other
partitions are not used to construct sepolicy (currently).
These changes can also fix#373, since we dynamically detect PARTNAME from device trees.
BusyBox is unable to run properly on non-root applications due to seccomp introduced in Android 8.0.
The SDK-21 libc.a has system call wrappers that uses the system calls on the whitelist, so binaries compiled with the updated libc can work properly.
1. Introduce new applet: imgtool for better separation from the main program
2. Actually mount the image and check statvfs for free space in the image
This shall eliminate any possible module installation failure from image resizing issues.
The &cmd will return a pointer which point to a pointer of cmdline.
It is a memory address which is usually 8 bytes in 64 bits machine.
However, the struct cmdline is 4 bytes. This will cause setting zero
beyond the bound.
Below is a simple example to show the differentiation:
struct cmdline {
char skip_initramfs;
char slot[3];
};
static void parse_cmdline(struct cmdline *cmd)
{
printf("%lu\n", sizeof(*cmd)); /* 4 */
printf("%lu\n", sizeof(&cmd)); /* 8 */
}
int main()
{
struct cmdline cmd;
parse_cmdline(&cmd);
return 0;
}
This patch prevents this.
Signed-off-by: npes87184 <npes87184@gmail.com>
In previous implementations, proc_monitor checks whether the mount namespace of an app is actually separated from zygote using a list generated at startup.
However, for some unknown reason, some devices (e.g. Samsung) has multiple zygote servers running in the background.
This means that app processes spawned from the unlisted zygotes are not checked whether the separation is done or not, causing MagiskHide unmount stuffs in the namespace of zygote, and since zygote is the "mother" of all apps, all apps will no longer have root access.
Since I'm not sure of the reason why multiple zygotes exists, so instead of checking the namespace against a list, compare the current namespace against the parent process's namespace.
This will make sure the namespace is NOT the same as the parent process, which is supposed to be the zygote server.
It's not important to check the return value of unlink(2) or even verify
that the file exists. If this code is running, it means the system has
rebooted, and thus the update file, if any, should be removed so that
MagiskManager doesn't keep displaying the same message. We also handle
this before we handle "disable" so that disabled modules don't keep
requesting a reboot to update.
