> > I remember asking - don't remember the answer - > > do you have any testing for this feature? > Yes, on an unnamed 4.19-based and mainline-based Android and virtual > cuttlefish product ... which was critically unworkable without this > patch series. Of course you *tested* it - I meant did you write any automated tests that other developers can run to verify that feature won't break with future changes. Many people run xfstests with overlayfs, where most of the tests run as root. Few people run unionmount testsuite with overlayfs where most of the tests run as root. So none of those tests have coverage for override_creds=off. > > I have a WIP branch to run unionmount-testsuite not as root, > > which is a start, but I didn't get to finish the work. > > Let me know if you want to take up this work. > Please refer it in private email to me, no guarantees, my cycles are so > sparse right now that it took a month to respin this patch series to > upstream. If I can make it test on Android with overlayfs activated, big > gain. It's here: https://github.com/amir73il/unionmount-testsuite/commits/run_as_bin As far as I can tell, the test code in the branch is working, but it fails on permissions in one of the early create file test cases and I did not have time to look into it. What it does is to drop capabilities to uid 1 before executing the test cases. In between test cases, for the test setup it reverts back to uid 0. For your Android use case, you may want to have uid's 0/1 configurable to different uid's? the first (setup) uid obviously needs to be capable of mounting overlayfs. Not sure how you would go about changing security context? Probably, you would need to have the test setup code execute "./run --ov --set-up" via init service command. Cheat sheet for running the test: pre requisite python3 sudo mkdir -p /lower /upper /mnt sudo ./run --ov Thanks, Amir.
