`/usr/bin/syscheck` is looking for the `initdb.sh` program to execute, which you're writing to run `/bin/bash` per these instructions. because `/usr/bin/syscheck` is being run with sudo privileges (root), anything it executes will be run as root. you can program initdb.sh with `chmod +s /bin/bash` and when you run `sudo /usr/bin/syscheck` it will set the SUID bit on `/bin/bash` - you can see this by running `ls -ld /bin/bash` after you run `sudo /usr/bin/syscheck` with that in `initdb.sh` - but that's all it will do, then to escalate to root user with SUID bit set on `/bin/bash` you'd then have to run `/bin/bash -p` for root. basically, you're tricking it to run ANY system command you have within `initdb.sh` as the root user, because this sudo command & program is running everything within it as root.

now, say this was not the case - you encounter a situation where you dont have sudo privileges, but you can run a `script.sh` which is owned by the root user. and within that script, it calls out to `another_script.sh` to run in its commands, and you have the ability to edit and trick it by modifying `another_script.sh` --- just because `script.sh` is owned by the root user, does not mean that `another_script.sh` will run as root. you would have to `chown root:root another_script.sh` in order to escalate, in you very well might not have success programming it to just run `/bin/bash` like the author recommended here. you'd simply use another system command or path, like i recommended by setting the SUID bit yourself on `/bin/bash` then running it with the -p flag.