[reduce CC list]

I am fine with this patch, but would like to request that you add @sb arg
to the ovl_revert_creds() helper, so it is more useful for other things in the
future that scope the underlying layers access (like shutdown).

Will respin and retest.

Apropos testing, I wanted to bring up this issue.
I noticed that the test coverage I have for unprivileged user access to
overlayfs is lacking.

xfstests has several generic tests that use _runas and run on overlayfs,
but that's only for pure upper files.

unionmount-testsuite is always run as root, because it needs to
mount/umount/etc.
I am working on a new mode ./run --ov --runas=1
to seteuid(1);setegid(1) before every test (after set_up and mount)
That's fine for basic UNIX permission and capability checks, but does not cover
more complex setups like with sepolicy.

I was thinking maybe to execute "./run --ov --set-up" with mounter process
credentials (e.g. initd) and then add a new mode "./run --ov --no-set-up"
which uses the mount prepared by the mounter and runs the tests.

I wanted to get feedback on the ideas above if they are useful for
your use cases? Is that enough or is there more functionality required
to cover more use cases?

Thanks,
Amir.

I had already filed an internal bug to find a solution for this because I did not have a full answer to this vacuum in testing. Everything I do is cumbersome, manual or instrumented w.r.t. overlayfs with a poor velocity because solution is checked on all android kernel releases; and relies on a functional device (can be run under emulator) to smoke test the integrated result (where we do have some automation).

These new problems that added extra patches to this series were only uncovered over the last two months of investigation and root cause on 4.14 and (very recently) 4.19 devices and have not discovered any automation (well, two simple tests is not enough) that pleases me.

We have no problem running functionality or security tests on "userdebug" (near identical to "user" builds that go to the planet) that is in effect rooted (su root <command>) and may have a limited few extra test or engineering excecutables, with a policy to upload them to /data/nativetest/ otherwise. Our standard POSIX tools are delivered from toybox, so keep that in mind.

I had looked at https://github.com/SELinuxProject/selinux-testsuite, but it could not easily be Android'ified because of reliance for on-target for Bash, Perl and Python. But I am sure there are many tests scenarios there that could be 'translated'.

An Android'ified test that would test sepolicy would probably leverage our existing policy (https://android.git.corp.google.com/platform/system/sepolicy/+/HEAD/) and free rein in /data/local/tmp/ to play mounting games.

Sincerely -- Mark Salyzyn