init: cannot execve('/system/bin/custom.sh'): Permission denied

Question

I have a rooted system-as-root Samsung Device and I am trying to run an init service which runs custom.sh script using u:r:su:s0 SELinux context.

# define service, use executable here if script not needed
service custom /system/bin/custom.sh

    # don't start unless explicitly asked to
    disabled

    # Use `seclabel u:r:magisk:s0` to run with unrestricted SELinux context to avoid avc denials
    # can also use "u:r:su:s0" on userdebug / eng builds if no Magisk.
    # It's required if SELinux is enforcing and service needs access
    # to some system resources not allowed by default sepolicy
    seclabel u:r:su:s0

# start the service when boot is completed
on property:sys.boot_completed=1
    # Use it to start the service
    start custom

As per my understanding, the rules for transition from init context to su context is not defined so, I should get avc: denial error.

But, I am getting permission denied error as following:

init: cannot execve('/system/bin/custom.sh'): Permission denied

I have checked the permission of custom.sh file and it is as following:

-r-xr-xr-- 1 root root 153 2019-11-04 13:25 /system/custom.sh

Please suggest what is happening here and how can I fix it?

Answer 1

As evident from init source code:

...
static bool ExpandArgsAndExecv(const std::vector<std::string>& args) {
    ...
    return execv(c_strings[0], c_strings.data()) == 0;
}
...
        if (!ExpandArgsAndExecv(args_)) {
            PLOG(ERROR) << "cannot execve('" << args_[0] << "')";
        }

For whatever reason if init fails to execute the script custom.sh (i.e. syscall execve returns non-zero exit code), you will get cannot execve error. Permission denied (EACCES) is returned by execve in multiple situations e.g. unable to read file path, no +x permission on binary or filesystem mounted with noexec. Inability to read|open|execute script or make context transition is returned as EACCES.

Also cannot execve is logged by init but avc: denied is logged by SELinux subsystem through audit subsystem or kernel logging. You should get both errors in dmesg or logcat -b events or logcat -b kernel. If you don't, may be there is a dontaudit rule defined for source or target or both contexts.

Please suggest what is happening here and how can I fix it?

As explained in my answer to your previous question: How to run an Android init service with superuser SELinux context? define SELinux rules to allow init read / execute custom.sh script and make transition to u:r:su:s0.