GeezerVison

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

All commit authors signed the Contributor License Agreement.

it's my first pr here so i don't know much about the NEWS entry, if it's not a problem can anyone tell me if i do need to add any NEWS entry ?

Documentation build overview

📚 cpython-previews | 🛠️ Build #34351207 | 📁 Comparing d4df9df against main (423ae0f)

  🔍 Preview build  

it's my first pr here so i don't know much about the NEWS entry, if it's not a problem can anyone tell me if i do need to add any NEWS entry ?

thanks for the PR, as per my thought yes, this will need NEWS entry but you can wait for the review and then you can add NEWS entry ( to get 100 % sure 😀)

i have another question for the Android test failure should i update the test_posix.py ? to do something like if support.is_android and os.getuid() != 0: so it will not failed on PermissionError ? or should i need to update something on my patch so the existing test pass

why did the Tests / Sanitizers / TSan (free-threading) (pull_request) failed i don't get it ?

We can see that the cause of one of the test failures probably is that the Python test suite has interpreted the unblocking of setresuid() as an indication that it should be usable as non-root user, even though we want to use it as root user and continue to show an error for non-root users;

I would say that yes, the test should probably be modified to check for Android platform, and in the case of Android platform, only test that function if the test is running as root user;

however, what I find concerning is that the CI here only produced a failure for x86_64, and not for aarch64, even though in my own separate test, both x86_64 and aarch64 architectures of Android should be returning the same result from the same function:

I wonder if that suggests there is a deeper problem with the tests or an inconsistency somewhere in the test implementation between x86_64 and aarch64.

@robertkirkman yes, let see what others are saying about this . I still didn't get any other comment from any of the core maintainers

Skipping tests: GitHub Actions does not support the Android emulator on this platform.

Ah I see, the aarch64 build does not run the test suite in CI, so if it did, it would also have that error.

It would be very useful to run the tests on aarch64 on GitHub Actions, but the macOS runner is apparently already a virtual machine, so it can't run the emulator.

another way to do that would be to obtain or build an unofficial build of the Android NDK for running on aarch64 GNU/Linux which could be used to build the testbed and run it in the managed emulator (technically virtual machine) contiguously on the same aarch64 GNU/Linux runner.

But the Android emulator isn't available for aarch64 Linux either. From this discussion, it sounds like it is possible to build it from source, but do you know of any downloadable build which is suitable for production use?

why did the Tests / Sanitizers / TSan (free-threading) (pull_request) failed i don't get it ?

Those tests are unreliable; you can ignore them for now.

But the Android emulator isn't available for aarch64 Linux either. From beeware/briefcase#449 (comment), it sounds like it is possible to build it from source, but do you know of any downloadable build which is suitable for production use?

yes, that's completely right; not only would an aarch64 build of the Android NDK probably be required, also an aarch64 build of the emulator would be, though the part of the emulator that I believe would need to be compiled is the part that is mostly formed from QEMU, and doesn't take as long to compile as the entire AVD image would take to build (which I think wouldn't be required), nor as long as the Android NDK would take to build. I agree, though, that both a custom emulator QEMU and a custom NDK are probably too complicated and involve too many unofficial steps for them to be worth using for CPython unless a pressing need for running the aarch64 Android tests in CI is found.

On Linux, apparently the set...id functions all allow an unprivileged process to set any of the IDs to any of the saved, effective or real IDs (i.e. the values returned by getres...id), or in some cases, -1 to leave the ID unchanged. You should test whether this is true on Android as well, and if so, update the code to allow the function to run under those circumstances. Then the test will pass.

I am not sure exactly what the matrix of crashing vs not crashing looks like for this beyond "some of the functions here cause crashing when called as non-root user", but I can confirm that not all of the functions appear to be able to crash the program, only certain ones or combinations of arguments with certain ones, since I just now checked these several and saw these results, on Samsung Galaxy S8+ SM-G955F with Android 16:

does not crash

#include <stdio.h>
#include <unistd.h>

int main(void) {
    printf("%d\n", setresuid(-1, -1, -1));
}

does not crash

#include <stdio.h>
#include <unistd.h>

int main(void) {
    uid_t r, e, s;
    getresuid(&r, &e, &s);
    printf("%d\n", setresuid(r, e, s));
}

does not crash

#include <stdio.h>
#include <unistd.h>

int main(void) {
    printf("%d\n", setresuid(0, 0, 0));
}

crashes with Unknown signal 31

#include <stdio.h>
#include <unistd.h>

int main(void) {
    printf("%d\n", setgid(0));
}

crashes with Unknown signal 31

#include <stdio.h>
#include <unistd.h>

int main(void) {
    printf("%d\n", chroot("/"));
}

for this reason, if others see similar results and we assume that all recent Android versions produce the same matrix of whether each function will cause a crash, it does seem like some, maybe including setresuid(), could be entirely unblocked, and then tested here as non-root user, while others such as chroot() and setgid() would need to remain blocked for non-root users, but I haven't tested and am not sure of what decisions should be made for all other functions or all possible combinations of argument values.

I have just finished creating a custom ROM of the Android Studio Android Virtual Device Android Emulator that has the popular KernelSU implementation of root for Android preconfigured into it. For all non-root tests of this PR this is not important, but for anyone interested in testing the root-only functionality, expand to read further.

@robertkirkman can you test it https://github.com/sabamdarif/termux-packages/actions/runs/28925155859 and see if posix.setresuid(-1, -1, -1) works for you or not , i test tested it and it didn't actually crash , can you verify that ?

Yes, for me that doesn't crash, when I test that build.

@mhsmith FTR, once we are in the beta cycle, we can't introduce features anymore. Only bug fixes are considered backportable.

I can confirm that not all of the functions appear to be able to crash the program

I found the same thing when experimenting with ctypes on API level 36:

>>> c = ctypes.CDLL(None, use_errno=True)
>>> c.setresuid(0, 0, 0)
-1
>>> os.strerror(ctypes.get_errno())
'Operation not permitted'

On this emulator, when passing all arguments as 0, setresuid and seteuid return an error, while setuid and setreuid crash the process.

I can't see any logical reason for this difference, so I guess it may be an oversight which they'll fix in a future version of Android. In which case, it's probably still safer for us to keep the checks in all the functions.

Based on the logcat message, the crash is evidently a deliberate security feature:

10:08:54.234 DEBUG            A  signal 31 (SIGSYS), code 1 (SYS_SECCOMP), fault addr --------
10:08:54.234 DEBUG            A  Cause: seccomp prevented call to disallowed arm64 system call 146

This occurs even for calls which are supposed to be allowed in unprivileged processes, such as setuid(getuid()).

So I think we should disregard what I said before about checking the argument values, keep blocking all the functions when getuid() != 0, and update the failing test instead.

!buildbot aarch64 android

🤖 New build scheduled with the buildbot fleet by @mhsmith for commit d4df9df 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F152977%2Fmerge

The command will test the builders whose names match following regular expression: aarch64 android

The builders matched are:

• aarch64 Android PR