[Magisk] Rstment ^m^:
Hello all!

Magisk script already exists that does this but I don't wanna use magisk due to performance overhead xd

I am building rom image with all thermal modifications applied to it already , including various other mods that one would use magisk for...

Basically this is what I need help with:

View attachment 5661313

This would need to be converted into a post fs service :

-place a script inside /system/bin

-create init.rc file that starts a new service which would then call and execute the script

As far as init.rc goes that looks very simple :

on property:sys.boot_completed=1 <<This needs to be replaced with post fs
start NewService

service NewService /system/bin/script.sh
user root
group root
oneshot

This looks simple enough but then how it is written above won't work due to SELinux permissions...

init warning: Service myservice needs a SELinux domain defined. Please fix.

type=1400 ... avc:denied ... scontext ... tcontext ... #some annoying warning messages like this

Another user chimed in and shared this snippet :

The issue what that I needed to add the line seclabel u:r:init:s0 to my init service.

The complete service now looks like this:

on property:sys.boot_completed=1 <<This needs to be replaced with post fs
start NewService

service NewService /system/bin/script.sh
seclabel u:r:init:s0 <<<<<
user root
group root
oneshot

Issue here is : Also note that SElinux must be set to permissive to allow this service to run or alternatively a policy must be set to allow the service to run.

Which I can't do ... leave SELinux permissive is a huge issue

Now , I found this which builds on how the selinux must be setup to a user that has access to files that the script is wanting to modify... who that user may be in my case scenario idk xd https://stackoverflow.com/a/55901362

Run into a very similar problem myself, and here's what I've found:

When you run ls -Z /system/bin/myservice and get this:

u:object_r:system_file:s0

it means that your file is in the system_file domain. Now that's not good, as system files are not supposed to be executed, or at last not during init (you may still be able to execute it later from terminal the usual way).

In my case I was lucky, 'cause I was replacing an existing system service with a customised one that I've compiled from source. This means I was able to check the security context of the original file I was replacing and that was from ls -Z /system/bin/myservice.bak :

u:object_r:myservice_exec:s0

So I updated my new file to the same using chcon u:object_r:myservice_exec:s0 /system/bin/myservice

After that it was working fine.

If you want to create a brand new service you may need to use a domain that exists in your sepolicies already, as simply setting it to myservice_exec, won't help, as that would be a non-existing domain in your case. If I were in your shoes and wanted to avoid defining custom policy I might try to find a service with similar security, check the domain on that and try to set the same to my service. init_exec may be a good candidate, but your mileage may vary...

What idk is how to check the selinux policy for all existing users and what access they might have... back to searching I guess unless u have some ideas?

I would like to do this without modifying kernel/system to make it permissive...