I've just started to explore the issue of the super partition, but it doesn't seem unsolvable. Complicated, yes (since there's at least EOFS and EXT4 DEDUP) but there are already scripts for that so I think people are learning about it.
BTW I now have adb running as root quite early, but not as early as I want, also it could be vulnerable to bugs since something kills it.
There's something funny going on at boot: adbd get started early, then restarted.
I'm trying to leverage that oddity to have the first adbd be run as root then the second as a normal shell (but only if boot succeed) for the 99% of the times when everything will work normally and the boot succeed, to avoid leaving a gaping security hole only required to fix problems 1% of the times during devel.
Right now I still don't understand why exactly this situation happens: I've read the very few pieces of documentation on android init.rc I could find, my initial impression is that it pales in comparison to systemd.
My findings so far:
1) the adbd socket that's required to run adbd is created twice, meaning it's run from some script
Code:
dmesg |grep adbd |grep 1000
[ 8.653049] init: Created socket '/dev/socket/adbd', mode 660, user 1000, group 1000
[ 19.553223] init: Created socket '/dev/socket/adbd', mode 660, user 1000, group 1000
2) The adbd at 8 seconds mean we could have a good and reliable way to connect, even if framework.jar is very bad and get the boot stuck.
I'm concerned about introducing problems for end users, something which could easily happen as we need to match the patched framework to the running one. Right now I'm thinking about using md5 to select which one to use in the magisk module.
@Renate or @CrazyCoder could you put your framework.jar and the patched version somewhere, so I can do its md5 and have a simple branching statement to use the correct framework.jar in the magisk module?
3) The adb restart is caused by some init.rc script.
Given the consistent timestamps across reboots, the restart seems to be due to sys.usb.configfs=0 being send by something which maybe shouldn't send it?
Check that:
Code:
# dmesg |grep sys.config.usb
[ 8.647572] init: processing action (sys.usb.config=adb && sys.usb.configfs=0) from (/system/etc/init/hw/init.usb.rc:37)
[ 8.648356] init: Command 'write /sys/class/android_usb/android0/enable 0' action=sys.usb.config=adb && sys.usb.configfs=0 (/system/etc/init/hw/init.usb.rc:38) took 0ms and failed: Unable to write to file '/sys/class/android_usb/android0/enable': open() failed: Permission denied
[ 8.648931] init: Command 'write /sys/class/android_usb/android0/idVendor 18d1' action=sys.usb.config=adb && sys.usb.configfs=0 (/system/etc/init/hw/init.usb.rc:39) took 0ms and failed: Unable to write to file '/sys/class/android_usb/android0/idVendor': open() failed: Permission denied
[ 8.649463] init: Command 'write /sys/class/android_usb/android0/idProduct 4EE7' action=sys.usb.config=adb && sys.usb.
configfs=0 (/system/etc/init/hw/init.usb.rc:40) took 0ms and failed: Unable to write to file '/sys/class/android_usb/android0/idProduct': open() failed: Permission denied
[ 8.649998] init: Command 'write /sys/class/android_usb/android0/functions ${sys.usb.config}' action=sys.usb.config=adb && sys.usb.configfs=0 (/system/etc/init/hw/init.usb.rc:41) took 0ms and failed: Unable to write to file '/sys/class/android_usb/android0/functions': open() failed: Permission denied
[ 8.650650] init: Command 'write /sys/class/android_usb/android0/enable 1' action=sys.usb.config=adb && sys.usb.configfs=0 (/system/etc/init/hw/init.usb.rc:42) took 0ms and failed: Unable to write to file '/sys/class/android_usb/android0/e
nable': open() failed: Permission denied
[ 9.217858] init: processing action (sys.usb.config=adb && sys.usb.configfs=1) from (/vendor/etc/init/hw/init.qcom.usb.rc:1633)
[ 9.228277] init: processing action (sys.usb.config=adb && sys.usb.configfs=1) from (/system/etc/init/hw/init.usb.configfs.rc:17)
[ 9.228340] init: processing action (sys.usb.config=adb && sys.usb.configfs=1 && sys.usb.ffs.ready=1) from (/system/etc/init/hw/init.usb.configfs.rc:20)
[ 9.294637] init: Command 'write /config/usb_gadget/g1/UDC ${sys.usb.controller}' action=sys.usb.config=adb && sys.usb.configfs=1 && sys.usb.ffs.ready=1 (/system/etc/init/hw/init.usb.configfs.rc:23) took 65ms and succeeded
[ 9.301022] init: processing action (sys.usb.config=adb && sys.usb.configfs=1 && sys.usb.ffs.ready=1) from (/system/etc/init/hw/init.usb.configfs.rc:20)
[ 9.305453] init: Command 'symlink /config/usb_gadget/g1/functions/ffs.adb /config/usb_gadget/g1/configs/b.1/f1' action=sys.usb.config=adb && sys.usb.configfs=1 && sys.usb.ffs.ready=1 (/system/etc/init/hw/init.usb.configfs.rc:22) took 3ms
Given the permission errors that happen for weird (and currently unknown) reasons, I think /system/etc/init/hw/init.usb.rc is the root cause of the problem.
/system/etc/init/hw/init.usb.configfs.rc seems to have no permission problem, but /system/etc/init/hw/init.usb.rc does accoding to dmesg.
/system/etc/init/hw/init.usb.rc interestingly contains a service line for /system/bin/adbd (where I can put an adbd), and a default value that could be the cause of the adbd restart.
I've tried playing with selinux perms but it didn't help:
Code:
service adbd /system/bin/adbd --root_seclabel u:r:magisk:s0
#--root_seclabel=u:r:su:s0
class core
socket adbd seqpacket 660 system system
updatable
seclabel u:r:magisk:s0
# seclabel u:r:adbd:s0
# Set default value on sys.usb.configfs early in boot sequence. It will be
# overridden in `on boot` action of init.hardware.rc.
on init
setprop sys.usb.configfs 0
I think I'm very close to figure what happens during early boot.
I'll keep exploring the issue and see if I can fix Onyx permissions for them lol