Magisk: ^C interrupt not working in root's bash shell

[seffparker]

Its a strange issue, only started recently. First, I thought it was with the terminal, but noticed all terminal emulators showing this issue.

When we hit Ctrl+C in BASH shell running as root user, it does nothing. No issues with user's bash, or root's SH shell.

I have tried different BASH binaries, and terminal emulators.

stty -a output as root user:
speed 38400 baud; rows 77; columns 106; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; -parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

[topjohnwu]

I think 99% it is caused by SELinux. May you try to turn selinux to permissive and see if things works now?

[seffparker]

Forgot to add it already. It was the same behavior regardless of SELinux states.

And tried three ^C methods. Hackers keyboard, volkey, termux extra-key-row. All of them works in non-root shell, and none works in root's shell.

[Geofferey]

Try a different terminal emulator. I haven't had ^C work in any of the built in terminals or Android terminal emulator since 7.0. I currently use Juicessh or Termius and modifier soft keys work just fine.

[mirfatif]

What do trap -p and grep Sig /proc/self/status show in bash script?

[seffparker]

Found some additional information.

If we invoke root's bash shell using /sbin/su -s /path/to/bash the ^C is not working.

Tried other indirect methods like switch to default shell sh by simply /sbin/su then switch to bash shell by /path/to/bash OR by /sbin/su -c /path/to/bash. The ^C works in the last two indirect methods.

[seffparker]

To conclude, the issue is now with magiskd (/sbin/su) invoking method. Hope you guys can fit it.

[mirfatif]

You didn't answer my question but what I can tell is that magiskd is blocking some signals:

~# grep Sig /proc/$(pgrep magiskd)/status
SigQ:   3/10391
SigPnd: 0000000000000000
SigBlk: fffffff87ffbfeff
SigIgn: 0000000000000000
SigCgt: 00000004400084f8

which are propagated to the forked process (shell in our case) when invoked with su -s but not with su -c. The reason is that _Ksh (both ksh93 and mksh;_ which /system/bin/sh is _) unblock all signals_. This can be elaborated, write a script test.sh:

#!/system/bin/sh

grep SigBlk /proc/self/status
trap 'echo; echo I am $NOT killed.' EXIT
sleep 5
NOT=NOT

Now:

~$ /sbin/su -c ./test.sh
SigBlk: 0000000000000000
^C
I am killed.
~$ /sbin/su -s /system/bin/bash -c ./test.sh
SigBlk: 0000000000000000
^C
I am killed.

So whether sh is executed (or forked?) directly from su or through bash, it doesn't block signals. Now change shebang to bash:

#!/system/bin/bash

grep SigBlk /proc/self/status
trap 'echo; echo I am $NOT killed.' EXIT
sleep 5
NOT=NOT

And test again:

~$ /sbin/su -c ./test.sh
SigBlk: 0000000000000000
^C
I am killed.
~$ /sbin/su -s /system/bin/bash -c ./test.sh
SigBlk: fffffff87ffafeff
^C^C^C
I am NOT killed.

Again if /system/bin/sh is involved (with su -c), signals aren't blocked. When bash was directly executed, they were blocked.

So this should be looked into from a developers's perspective, which I'm not.

[topjohnwu]

@mirfatif huge thanks for the info :), I know how to fix this issue now