[Magisk] Sebastl:
[MENTION=5065917]BertlBrown[/MENTION]

I like that approach. Stabbing from the back - it is working, but it is just a workaround. Ill try modifying the script when i ve got time.

Edit: I was 1000% sure that i unmounted the sdcardfs, but it wasnt - or playing another trick on me. Was working with Terminal and ADB

Edit2: Sounds like Namespace Separation

Nonetheless, with the mount apparently still in place, i finally didnt get a Read-Only FS, but correct SELinux denials like

After adding the following policy or switching to permissive

Writing finally worked

Then i tried to install 0sm0sis busybox module to see what happens.

Suddenly i caught alot of denials of untrusted_app accessing/writing.

Turns out it is the installer script and the binaries it calls.

When i checked the MagiskManager installer log, writing to /dev/magisk_merge fails because of............READ-ONLY FS

Not again...

The binaries called in the installer script are essentually toybox or toolbox and they definitely have an own SE context (u:object_r:toolbox_exec:s0)

So why are they showing up as untrusted app ?

And why is (even in permissive) /dev Read-Only now, too?

I stripped the /sepolicy from the bootimg and compared to /sepolicy from the running system. Interesting to see how many rules magisk adds ;)

A few things were suspicious. I did the same approach for an Android 6 / Kernel v3.18.22 device from September 2017 and compared against the problematic one.

Fact 1 A lot of entries concerning su target context are missing :

allow adbd su : binder { call transfer } ;

allow adbd su : fd use ;

allow adbd toolbox_exec : file { ioctl read getattr lock execute execute_no_trans open } ;

allow shell su : binder { call transfer } ;

allow shell su : fd use ;

allow shell su : process { transition siginh rlimitinh } ;

allow shell su_exec : file { read getattr execute open } ;

allow vold su : binder { call transfer } ;

allow vold su : fd use ;

In the problematic one, the su_exec is replaced by allow shell sysenv_daemon_exec : file { ioctl read getattr lock execute execute_no_trans open } ;

Question 1: Would that explain that the binaries from the busybox install attempt run as untrusted_app and therefore dont get the permissions ?

Question 2: Is the binder { call transfer } replaced by the sysenv_daemon_exec (Android 6 => 7?) ?

Fact 2 A lot of entries concerning su source context are missing:

allow su aal : binder transfer ;

allow su adbd : binder transfer ;

allow su aee_core_forwarder : binder transfer ;

allow su agoldnvram : binder transfer ;

allow su akmd09911 : binder transfer ;

allow su akmd09912 : binder transfer ;

allow su akmd8963 : binder transfer ;

allow su akmd8975 : binder transfer ;

allow su ami304d : binder transfer ;

allow su app_data_file : dir { ioctl read write create getattr setattr rename add_name remove_name reparent search rmdir open } ;

.

.

.

See Questions from Fact 1.

Fact 3 concerning vold

allow vold block_device : blk_file { ioctl read write create getattr setattr lock append unlink rename open } ;

allow vold block_device : dir { ioctl read write create getattr setattr rename add_name remove_name reparent search rmdir open } ;

allow vold block_device : file create ;

The last two entries are identical, but the first one is missing. Could it be the culprit for the mount problem at boot ?

At least in my logs vold : handleBlockEvent with action 3, DEVPATH: /devices/virtual/block/loop0 happens directly before the mount failing with Permission 13

[MENTION=1662773]mods[/MENTION]: Are you still okay with that research happening here ? It has to do with magisk getting to work properly, but it seems more like a general problem

Why does this f****g phone switch to Read-Only and NOT throw any denials without this sdcardfs trick ??? Connected to Fact 3 ?

Looking forward to suggestions!