I'am used to start a service in the android boot image with inherited context of the init.rc script (u:r:init:s0). In Android 5.0.2 (Samsung), my service does not inherity the init context anymore, it has to be set explicitly. The tool sesearch allowes to find the corresponding domain to the filetype. This is an output of a rootfs executable search:

allow init_shell rootfs: file { ioctl read execute open ... }

This means that the init_shell context is able to execute rootfs labled files.

-rwxr-xr-x  system  system  u:object_r:rootfs:s0  my_binary

But if I set the init_shell label of my service in the init.rc script (running as init) , I still got permission denied in the dmsg output.

service my_service /my_binary
    user root
    seclabel u:r:init_shell:s0

Does this error refers to the executing of the service, meaning the init_shell context does not have permission to execute a rootfs file or does it mean that init is not allowed to set the init_shell context?

I've already tried other contexts like "shell" > "shell_exec" with the same result.

If I do not set the context, I receive a warning about a missing selinux context, but the file will be executed, unfortunately without the needed permissions.


Injecting the permissive statement to the init_shell context works. Is there no other way to use existing contexts to stay enforced? my_binary should run as deamon with init_shell context to hand over its context to other processes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.