Internal Details

File Structure

Paths in “Magisk tmpfs directory”

Magisk will mount a tmpfs directory to store some temporary data. For devices with the /sbin folder, it will be chosen as it will also act as an overlay to inject binaries into PATH. From Android 11 onwards, the /sbin folder might not exist, so Magisk will use /debug_ramdisk as the base folder.

# In order to get the current base folder Magisk is using,
# use the command `magisk --path`.
# Binaries like magisk, magiskinit, and all symlinks to
# applets are directly stored in this path. This means when
# this is /sbin, these binaries will be directly in PATH.
MAGISKTMP=$(magisk --path)

# Magisk internal stuffs

# /data/adb/modules will be bind mounted here.
# The original folder is not used due to nosuid mount flag.

# The current Magisk installation config

# Partition mirrors
# Each directory in this path will be mounted with the
# partition of its directory name.
# e.g. system, system_ext, vendor, data ...

# Root directory patch files
# On system-as-root devices, / is not writable.
# All pre-init patched files are stored here and bind mounted.

Paths in /data

Some binaries and files should be stored on non-volatile storages in /data. In order to prevent detection, everything has to be stored somewhere safe and undetectable in /data. The folder /data/adb was chosen because of the following advantages:


# Folder storing general post-fs-data scripts

# Folder storing general late_start service scripts

# Magisk modules

# Magisk modules that are pending for upgrade
# Module files are not safe to be modified when mounted
# Modules installed through the Magisk app will be stored here
# and will be merged into $SECURE_DIR/modules in the next reboot

# Database storing settings and root permissions

# All magisk related binaries, including busybox,
# scripts, and magisk binaries. Used in supporting
# module installation, addon.d, the Magisk app etc.

Magisk Booting Process


magiskinit will replace init as the first program to run.


This triggers on post-fs-data when /data is decrypted and mounted. The daemon magiskd will be launched, post-fs-data scripts are executed, and module files are magic mounted.


Later in the booting process, the class late_start will be triggered, and Magisk “service” mode will be started. In this mode, service scripts are executed.


Usually, system properties are designed to only be updated by init and read-only to non-root processes. With root you can change properties by sending requests to property_service (hosted by init) using commands such as setprop, but changing read-only props (props that start with ro. like and deleting properties are still prohibited.

resetprop is implemented by distilling out the source code related to system properties from AOSP and patched to allow direct modification to property area, or prop_area, bypassing the need to go through property_service. Since we are bypassing property_service, there are a few caveats:

SELinux Policies

Magisk will patch the stock sepolicy to make sure root and Magisk operations can be done in a safe and secure way. The new domain magisk is effectively permissive, which is what magiskd and all root shell will run in. magisk_file is a new file type that is setup to be allowed to be accessed by every domain (unrestricted file context).

Before Android 8.0, all allowed su client domains are allowed to directly connect to magiskd and establish connection with the daemon to get a remote root shell. Magisk also have to relax some ioctl operations so root shells can function properly.

After Android 8.0, to reduce relaxation of rules in Android’s sandbox, a new SELinux model is deployed. The magisk binary is labelled with magisk_exec file type, and processes running as allowed su client domains executing the magisk binary (this includes the su command) will transit to magisk_client by using a type_transition rule. Rules strictly restrict that only magisk domain processes are allowed to attribute files to magisk_exec. Direct connection to sockets of magiskd are not allowed; the only way to access the daemon is through a magisk_client process. These changes allow us to keep the sandbox intact, and keep Magisk specific rules separated from the rest of the policies.

The full set of rules can be found in sepolicy/rules.cpp.