search

RikkaApps / Riru

Inject into zygote process
4.86k stars 568 forks source link

Riru v25 does not load #203

Closed Kazurin-775 closed 3 years ago

Kazurin-775 commented 3 years ago

Information:

Logs:

Full boot log: logcat-20210324-2207.log

Describe the bug:

After an update to Riru v25, the Riru app shows that Riru is not installed, and all Riru modules do not take effect.

The logcat says:

01-12 16:44:53.231   801   801 E Riru    : dlopen /dev/6nEXc9/.magisk/modules/riru-core/lib/libriru.so: dlopen failed: library "/dev/6nEXc9/.magisk/modules/riru-core/lib/libriru.so" not found
01-12 16:44:53.238   800   800 E Riru64  : dlopen /dev/6nEXc9/.magisk/modules/riru-core/lib64/libriru.so: dlopen failed: library "/dev/6nEXc9/.magisk/modules/riru-core/lib64/libriru.so" not found

But these 2 files do exist if I check them manually, e.g.:

wayne:/ # ls -lZ /dev/6nEXc9/.magisk/modules/riru-core/lib/libriru.so
-rw-r--r-- 1 root root u:object_r:system_file:s0  1982708 2021-03-24 22:05 /dev/6nEXc9/.magisk/modules/riru-core/lib/libriru.so
RikkaW commented 3 years ago 
01-12 16:44:53.236   800   800 W main    : type=1400 audit(0.0:123): avc: denied { search } for name="riru-core" dev="mmcblk0p64" ino=1089616 scontext=u:r:zygote:s0 tcontext=u:object_r:adb_data_file:s0 tclass=dir permissive=0

This is the root cause, the context for at least one of the folders at every level of /dev/6nEXc9/.magisk/modules/riru-core/lib(64) has become u:object_r:adb_data_file:s0. Please check it.

Under normal circumstances, modules and its child should have u:object_r:system_file:s0 context.

Kazurin-775 commented 3 years ago

You're right, it seems that modules/riru-core and modules/riru-core/{lib,lib64,system} are automatically relabelled to u:object_r:adb_data_file:s0 during boot, but other files like module.prop remain unchanged. Strange.

I think there is no SELinux magic installed or running. What other information should I provide?

RikkaW commented 3 years ago

Try reset them back to u:object_r:system_file:s0, does it get relabelled again after reboot?

I know everything in /data will be "restorecon" on boot, but init does not have permission to run restorecon on system_file.

W init    : type=1400 audit(0.0:111): avc: denied { relabelfrom } for name="modules" dev="dm-5" ino=23017 scontext=u:r:init:s0 tcontext=u:object_r:system_file:s0 tclass=dir permissive=0

Use magiskpolicy --save to save current policies to a file and use sesearch, sesearch --allow -s init -t system_file -p relabelfrom, to check if init has the permission.

Kazurin-775 commented 3 years ago

Try reset them back to u:object_r:system_file:s0, does it get relabelled again after reboot?

Yes. I followed your instructions, and found out that init actually has relabel permission on directories:

$ sesearch --allow -s init -t system_file -p relabelfrom test.policy
allow init system_file:dir { add_name getattr ioctl lock mounton open read relabelfrom remove_name rmdir search watch watch_reads write };

On the other hand, init does not have permission to relabel files, so all files stay unchanged. This is almost consistent with my observation (except for /data/adb/modules/ itself, which remains system_file for unknown reason).

Is this due to the ROM I'm using?

RikkaW commented 3 years ago

To access a file, the search permission of upper folders is required, so if the folders are relabeled, the zygote cannot access the file inside.

AOSP does not have has this rule. https://cs.android.com/android/platform/superproject/+/android-11.0.0_r1:system/sepolicy/public/init.te;l=199, system_file_type is explicitly excluded.

Maybe your ROM maintainer brainlessly uses audit2allow to added all denied rules 🙃, this is absolutely wrong. Ask your ROM maintainer not to do this or switch to other ROMs.

shengruoyu commented 3 years ago

Try reset them back to u:object_r:system_file:s0, does it get relabelled again after reboot?

I know everything in /data will be "restorecon" on boot, but init does not have permission to run restorecon on system_file.

W init    : type=1400 audit(0.0:111): avc: denied { relabelfrom } for name="modules" dev="dm-5" ino=23017 scontext=u:r:init:s0 tcontext=u:object_r:system_file:s0 tclass=dir permissive=0

Use magiskpolicy --save to save current policies to a file and use sesearch, sesearch --allow -s init -t system_file -p relabelfrom, to check if init has the permission.

I followed the posts above, and got this:

sesearch: inaccessible or not found

Kazurin-775 commented 3 years ago

sesearch: inaccessible or not found

sesearch belongs to Linux package setools. See https://github.com/SELinuxProject/setools.

This issue is already closed, so please do not comment if your information is off-topic. Thanks for your support.