install magisk leaves /data/adb/magisk non-executable, so Zygisk silently never initialises #283

New Issue

2026-08-29T19:48:40-04:00

MisterWizzard commented

2026-08-29 19:48:40 -04:00

(Migrated from github.com)

Summary

install magisk produces a working root, but Zygisk can never initialise. The Magisk app
reports Zygisk: No regardless of the Zygisk setting, and no error is shown anywhere to explain
why. This breaks every Zygisk module (LSPosed, Shamiko, PlayIntegrityFix, …).

The cause is a file-permission bug in Magisk.setup(): the copy it makes into
<data_dir>/adb/magisk is left 0644, so /data/adb/magisk/magisk64 is not executable.

Root cause

General.install() runs in this order:

self.copy()       # writes the overlay tree; shutil.copyfile does not carry an exec bit
self.extra1()     # -> Magisk.setup() -> copytree(overlay, <data_dir>/adb/magisk)
...
self.set_perm()   # walks only self.files, i.e. paths under copy_dir (the overlay)

set_perm() iterates self.files, which for Magisk is
["etc/init/magisk", "etc/init/bootanim.rc"], joined against copy_dir. So it fixes the
overlay copy to 0755 and never touches the /data/adb/magisk copy that setup() made a
moment earlier. Those files keep the 0644 they inherited from the apk extraction.

At boot, magisk_env() cannot execute /data/adb/magisk/magisk64 and bails out at
post-fs-data. su still works, because that path runs from the overlay copy — which is
exactly what makes this so hard to diagnose.

Evidence

Before (stock install magisk):

$ ls -l /data/adb/magisk/magisk64
-rw-r--r-- 1 root root 333032 magisk64          <-- not executable

Magisk app:  Zygisk: No
/proc/<zygote64>/maps:  0 zygisk mappings

After chmod 0755 /data/adb/magisk/* and a restart, with nothing else changed:

$ ls -l /data/adb/magisk/magisk64
-rwxr-xr-x 1 root root 333032 magisk64

/cache/magisk.log:
  zygisk64: replaced com/android/internal/os/Zygote#nativeForkAndSpecialize
  zygisk64: replaced com/android/internal/os/Zygote#nativeForkSystemServer
  zygisk64: replaced com/android/internal/os/Zygote#nativeSpecializeAppProcess

/proc/<zygote64>/maps:  6 zygisk mappings
$(magisk --path)/.magisk/zygisk/: libzygisk.so.64, libzygisk-ld.so.64

Zygisk modules install and load normally after that.

Note for anyone debugging this

/debug_ramdisk is not a valid check on this installer — magisk --path is
/dev/magisk_<random>, so /debug_ramdisk stays empty even when Zygisk is working perfectly.
Use grep -c zygisk /proc/$(pgrep -f zygote64 | head -1)/maps instead.

Fix

Have setup() fix the permissions on the copy it just made, matching what
Magisk.set_path_perm() already applies to magisk paths (0o755). Four functional lines.

I have a PR ready with the patch plus a regression test that passes with the fix and fails
without it.

Environment

waydroid_script @ d5289cf
Waydroid 1.6.3, Fedora 44, mount_overlays = True
Android 13 (LineageOS 20 VANILLA, waydroid_x86_64), Magisk Delta 26301

### Summary `install magisk` produces a working root, but **Zygisk can never initialise**. The Magisk app reports `Zygisk: No` regardless of the Zygisk setting, and no error is shown anywhere to explain why. This breaks every Zygisk module (LSPosed, Shamiko, PlayIntegrityFix, …). The cause is a file-permission bug in `Magisk.setup()`: the copy it makes into `<data_dir>/adb/magisk` is left `0644`, so `/data/adb/magisk/magisk64` is not executable. ### Root cause `General.install()` runs in this order: ```python self.copy() # writes the overlay tree; shutil.copyfile does not carry an exec bit self.extra1() # -> Magisk.setup() -> copytree(overlay, <data_dir>/adb/magisk) ... self.set_perm() # walks only self.files, i.e. paths under copy_dir (the overlay) ``` `set_perm()` iterates `self.files`, which for `Magisk` is `["etc/init/magisk", "etc/init/bootanim.rc"]`, joined against `copy_dir`. So it fixes the **overlay** copy to `0755` and never touches the `/data/adb/magisk` copy that `setup()` made a moment earlier. Those files keep the `0644` they inherited from the apk extraction. At boot, `magisk_env()` cannot execute `/data/adb/magisk/magisk64` and bails out at `post-fs-data`. `su` still works, because that path runs from the overlay copy — which is exactly what makes this so hard to diagnose. ### Evidence Before (stock `install magisk`): ``` $ ls -l /data/adb/magisk/magisk64 -rw-r--r-- 1 root root 333032 magisk64 <-- not executable Magisk app: Zygisk: No /proc/<zygote64>/maps: 0 zygisk mappings ``` After `chmod 0755 /data/adb/magisk/*` and a restart, with nothing else changed: ``` $ ls -l /data/adb/magisk/magisk64 -rwxr-xr-x 1 root root 333032 magisk64 /cache/magisk.log: zygisk64: replaced com/android/internal/os/Zygote#nativeForkAndSpecialize zygisk64: replaced com/android/internal/os/Zygote#nativeForkSystemServer zygisk64: replaced com/android/internal/os/Zygote#nativeSpecializeAppProcess /proc/<zygote64>/maps: 6 zygisk mappings $(magisk --path)/.magisk/zygisk/: libzygisk.so.64, libzygisk-ld.so.64 ``` Zygisk modules install and load normally after that. ### Note for anyone debugging this `/debug_ramdisk` is **not** a valid check on this installer — `magisk --path` is `/dev/magisk_<random>`, so `/debug_ramdisk` stays empty even when Zygisk is working perfectly. Use `grep -c zygisk /proc/$(pgrep -f zygote64 | head -1)/maps` instead. ### Fix Have `setup()` fix the permissions on the copy it just made, matching what `Magisk.set_path_perm()` already applies to magisk paths (`0o755`). Four functional lines. I have a PR ready with the patch plus a regression test that passes with the fix and fails without it. ### Environment - waydroid_script @ d5289cf - Waydroid 1.6.3, Fedora 44, `mount_overlays = True` - Android 13 (LineageOS 20 VANILLA, waydroid_x86_64), Magisk Delta 26301

wbruno referenced this issue from a commit

2026-10-12 14:00:22 -04:00

Fix /data/adb/magisk permissions so Zygisk can initialise

wbruno closed this issue

2026-10-12 14:00:22 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wbruno/waydroid_script#283