Phone's architecture name changes when running under sudo/tsu

[FreddieOliveira]

Problem description
Not sure if this is an intended behavior or a bug, but when running uname -m the arch string is aarch64, but when running it with sudo or after running tsu the result is armv8l. This may lead to unexpected behavior depending on the program being run, since some programs do not treat aarch64 and armv8l the same.

Steps to reproduce

[Deleted user]

Make sure sudo doesn't pick the 32bit version of uname. It can be in /su/bin, /sbin, /system/bin or /system/xbin.

[FreddieOliveira]

I don't think that's the problem. I further investigated this and realized that my phone has two different uname binaries: /bin/uname symlink to /system/bin/toybox and /data/data/com.termux/files/usr/bin/uname symlink to /data/data/com.termux/files/usr/bin/coreutils. Both of them are 64 bit as shown bellow.

/system/bin/toybox

/data/data/com.termux/files/usr/bin/coreutils

[Deleted user]

Coreutils use uname() syscall to obtain information from kernel. Neither Termux nor coreutils by itself change it in any way.

strace -s1000 -v -e trace=uname uname
uname({sysname="Linux", nodename="localhost", release="3.18.91-15877854-QB29744875", version="#1 SMP PREEMPT Mon Mar 9 17:41:37 KST 2020", machine="aarch64", domainname="localdomain"}) = 0

There is a chance that sudo preloads something that hijacks system calls.

[Deleted user]

Could you run sudo which uname ? Rooting tools may install a custom binaries into /sbin, /su/bin or /sbin/bin which are available in PATH before anything else.

[FreddieOliveira]

Rooting tools may install a custom binaries into /sbin, /su/bin or /sbin/bin which are available in PATH before anything else

At first I also thought that, but if you look close at the screenshots, you'll notice I executed the commands using its absolute path and still the problem occurred. Here, without all my terminal visual noise:

$ sudo which uname
/data/data/com.termux/files/usr/bin/uname

$ which uname
/data/data/com.termux/files/usr/bin/uname

$ md5sum $(sudo which uname)
9e47aca3e38e68b12f3323cf94e6fe0b  /data/data/com.termux/files/usr/bin/uname

$ md5sum $(which uname)
9e47aca3e38e68b12f3323cf94e6fe0b  /data/data/com.termux/files/usr/bin/uname

$ /data/data/com.termux/files/usr/bin/uname -m
aarch64

$ sudo /data/data/com.termux/files/usr/bin/uname -m
armv8l

$ /system/bin/toybox uname -m
aarch64

$ sudo /system/bin/toybox uname -m
armv8l

$ /data/data/com.termux/files/usr/bin/coreutils --coreutils-prog=uname -m
aarch64

$ sudo /data/data/com.termux/files/usr/bin/coreutils --coreutils-prog=uname -m
armv8l

$ strace -v -e trace=uname /data/data/com.termux/files/usr/bin/uname -m
uname({sysname="Linux", nodename="localhost", release="4.4.225-Predator-Stormbreaker-7.2-DockerSupport", version="#5 SMP PREEMPT Sun Jun 14 22:12:18 -03 2020", machine="aarch64", domainname="localdomain"}) = 0

$ sudo strace -v -e trace=uname /data/data/com.termux/files/usr/bin/uname -m
uname({sysname="Linux", nodename="localhost", release="4.4.225-Predator-Stormbreaker-7.2-DockerSupport", version="#5 SMP PREEMPT Sun Jun 14 22:12:18 -03 2020", machine="armv8l", domainname="localdomain"}) = 0

[FreddieOliveira]

After reading the /data/data/com.termux/files/usr/bin/tsu script I realized the problem is actually with Magisk. It offers its own busybox binary at /sbin/.magisk/busybox, but this binary is 32bit. There's two possible solutions for this:

1. Don't change the PATH to use magisk's busybox by rewriting this line: exec "/sbin/su" -c "PATH=$BB_MAGISK env -i $ENV_BUILT $STARTUP_SCRIP as exec "/sbin/su" -c "env -i $ENV_BUILT $STARTUP_SCRIP

2. Execute setarch linux64 right after going root by changing the $STARTUP_SCRIPT variable.

[Deleted user]

Don't change the PATH to use magisk's busybox by rewriting this line

This should be reported to https://github.com/cswl/tsu.

[Deleted user]

@cswl