> "I guess it rewrite syscalls that would otherwise fail for lack of privileges"
That's not how access control works (on most systems). The system calls are still issued from a single process. If the gVisor process is running in the context of a non-privileged user, the system calls will fail regardless of the codepath.
It rewrites the syscalls to make them succeed: reading a privileged file? Rewrite to read a non-privileged shadow file. Killing a privileged process? Return success without killing anything, etc.
Whatever is not rewritten will fail in kernel: there is no security risk.
Imagine some applications expect the syscall to actually fail (ie. some odd way to test permissions).
I fail to grasp how this is a strength. Pulling the rug from under applications is dangerous. You're in a direct battle with internal implementation specifics - you don't want to get into that as an abstraction layer. You don't want to tailor various hacks for specific applications.
In a way, they have made an advanced version of the old fakeroot (a LD_PRELOAD magic thing--thus very limited in scope.)