3.5.0 fails under termux

[rimugu]

rsync: [Receiver] change_dir#1 "/sdcard/" failed: Permission denied (13)
rsync error: errors selecting input/output files, dirs (code 3) at main.c(768) [Receiver=3.5.0]
rsync: [sender] write error: Broken pipe (32)
rsync error: error in socket IO (code 10) at io.c(849) [sender=3.2.7]

fix is downgrade to 3.4.4

curl --parallel --keepalive-time 5 --location --ipv4 --output /sdcard/rsync/rsync_3.4.4_aarch64.deb --url https://termux.librehat.com/apt/termux-main/pool/main/r/rsync/rsync_3.4.4_aarch64.deb
dpkg -i /sdcard/rsync/rsync_3.4.4_aarch64.deb

[steadytao]

Yeah, I know what is causing this. Last regression I am addressing before I get some more sleep and will return in the afternoon 😭

[ketas]

i can't believe this happened again

[steadytao]

i can't believe this happened again

Any ideas on how we can improve our Termux coverage? I do not use Termux myself nor do I believe any active contributors do. Lets please be productive rather than complaining while people are trying to triage release-week problems. A test case, CI setup or help maintaining that platform would be useful.

[ketas]

i don't know how. maybe termux devs have ideas or they are willing to test it

since it happened again, they probably didn't test it. or tested in different way

if somebody have reminded me to test it, it would have not happened. or any other termux users

but i guess it wouldn't be hard to setup emulator

tho, rsync is used everywhere and i can't even imagine all platforms to test on

i would guess manual user test maybe? would be best

how do i know

the "i can't believe this happened again" was purely because i assumed that it's now tested and will not happ4n

[ketas]

... will not happen again

nothing else

[imagebuilder1837]

I can confirm this on Termux with rsync 3.5.0.

The destination itself is accessible from the same SSH session and security context. For example, this succeeds:

cd /storage/emulated/0/Documents/example
touch .test
rm .test

However, rsync 3.5.0 fails with:

rsync: [Receiver] change_dir#1 "/storage/emulated/0/Documents/example" failed: Permission denied (13)

I also tested the direct /storage/emulated/0/... path instead of Termux's ~/storage/shared symlink, with the same result, so this does not appear to be caused by the storage/shared symlink itself.

A diagnostic wrapper confirmed that the shell can cd to the exact destination immediately before exec rsync, while rsync then fails on the same path.

strace identifies the failure more precisely:

newfstatat(AT_FDCWD, "/storage/emulated/0/Documents/example",
           {st_mode=S_IFDIR|S_ISGID|0770, ...}, 0) = 0

openat(AT_FDCWD, "/", O_RDONLY|O_CLOEXEC|O_DIRECTORY)
    = -1 EACCES (Permission denied)

So the destination path is successfully resolved/stat'ed. The failure happens when the new 3.5.0 hardened path traversal tries to open / with O_RDONLY|O_DIRECTORY.

This seems consistent with Android/Termux allowing traversal through / to known paths while not allowing an untrusted app process to open the root directory for reading.

PR #1052 (O_PATH for directory traversal) appears to address exactly this case. The strace above also suggests that the issue is specifically the requirement to O_RDONLY-open the traversal anchor rather than an actual lack of access to the destination.

[steadytao]

@ketas Termux was not tested because none of the active contributors use it. We cannot feasibly personally remind users of every platform before each release. If you are willing to test release candidates on Termux, that would genuinely help prevent this happening again. Otherwise, please do not assume coverage exists and then complain when it does not; as you stated, I cannot imagine the amount of platforms we would have to test on to cover every possible use-case.

[ketas]

unsure why everyone seems like as if attacked here?

but yeah, i knew new rsync was coming out but i assumed there will be no issues anymore

altho last one was rare older android issue

i think rsync releases are still quite rare that i can test them manually

or i assume there are more users other than me, i bet we can find enough testers

from what i get, this is another overagressive security patch

anyway, i'm interested in testing them so by the time the release comes i don't need to downgrade :)

[ribbons]

@steadytao, feel free to use my PR #920 as a basis for running the test suite under Android if there is interest within the project in doing that. As I got no feedback after several requests I assumed there wasn't.

[robertkirkman]

Any ideas on how we can improve our Termux coverage? I do not use Termux myself nor do I believe any active contributors do. Lets please be productive rather than complaining while people are trying to triage release-week problems. A test case, CI setup or help maintaining that platform would be useful.

Hello, the KVM-based solution in #920 is one option, which can have high accuracy, but requires a lot of setup and takes a long time to spin up.

There is also another option which is termux-docker, which can be run in the docker command directly in GitHub Actions regular steps, but can also, with some workarounds and setup, be used with the GitHub Actions container: directive to have every command in each step in the job run inside the Termux. My example for that is here:

https://github.com/robertkirkman/termux-on-gha/blob/master/.github/workflows/build-and-test.yml

[robertkirkman]

termux-docker has somewhat lower accuracy of bare metal Android's behavior than regular KVM-based Android AVD emulators, but it is able to reproduce at least this specific recent problem with rsync.

Example of some basic commands and current output in termux-docker as an introduction:

~ $ mkdir test_dir
~ $ rsync a.out test_dir/
rsync: [Receiver] change_dir#1 "/data/data/com.termux/files/home/test_dir/" failed: Permission denied (13)
rsync error: errors selecting input/output files, dirs (code 3) at main.c(768) [Receiver=3.5.0]
~ $ pwd
/data/data/com.termux/files/home
~ $ termux-info
/data/data/com.termux/files/usr/bin/getprop: 3: exec: /system/bin/getprop: not found
/data/data/com.termux/files/usr/bin/getprop: 3: exec: /system/bin/getprop: not found
/data/data/com.termux/files/usr/bin/getprop: 3: exec: /system/bin/getprop: not found
/data/data/com.termux/files/usr/bin/getprop: 3: exec: /system/bin/getprop: not found
/data/data/com.termux/files/usr/bin/getprop: 3: exec: /system/bin/getprop: not found
/data/data/com.termux/files/usr/bin/getprop: 3: exec: /system/bin/getprop: not found
/data/data/com.termux/files/usr/bin/getprop: 3: exec: /system/bin/getprop: not found
Termux Variables:
unsupported
Packages CPU architecture:
i686
Subscribed repositories:
# sources.list
deb https://packages-cf.termux.dev/apt/termux-main stable main
# x11-repo (sources.list.d/x11.list)
deb https://packages-cf.termux.dev/apt/termux-x11 x11 main
Updatable packages:
All packages up to date
termux-tools version:
1.45.0
Android version:

Kernel build information:
Linux acc8d5b195b6 6.18.32-p2-gentoo-dist #1 SMP PREEMPT_DYNAMIC Mon May 25 02:11:07 CDT 2026 i686 Android
Device manufacturer:

Device model:

Supported ABIs:
SUPPORTED_ABIS: 
SUPPORTED_32_BIT_ABIS: 
SUPPORTED_64_BIT_ABIS: 
LD Variables:
LD_LIBRARY_PATH=
LD_PRELOAD=/data/data/com.termux/files/usr/lib/libtermux-exec-ld-preload.so
~ $ 

showing it reproducing this issue, showing its home folder path, and showing its termux-info output; termux-docker doesn't support the getprop command, so that is an example of one of the typical ways it differs from/is inaccurate to regular bare metal Android.

[robertkirkman]

since it happened again, they probably didn't test it. or tested in different way

if somebody have reminded me to test it, it would have not happened. or any other termux users

in termux, updates of rsync are directly deployed (with an automated script and no maintainer intervention) to all users without runtime testing, only build testing. in Termux, it builds -> it ships.

clearly that has tradeoffs, but that is not my decision! It is something almost all of Termux has done for years before I started contributing to Termux.