Regardless which mechnism you pick, it does create a weird situation: conceptually unpriv user objects (processes, files, cgroups, …) are owned by UIDs that are under user control, but without this UID-UID ownership being directly known to the kernel. IOW: the only way to interact with those objects without privs is for the user to go through namespacing similar to how they were originally created. If user code tries to interact with them without going through userns, these objects will appear…

…as foreign UID owned.

(Well, handling of processes is slightly less complex than files/cgroups here, since during their runtime they retain attachment to the userns they where created with, and that userns remains owned by the user's UID, which gives it magic powers. But files and cgroups don't work that way: file system objects "at rest" retain no binding to the userns, and thus no such magic powers from the original user's UID remains)