Concept of "root" privilege is spread into various control mechanism:
- Hardware: Intel CPU (and all other CPU generally) have various "privileged state" - and in each of these privileged state you can or cannot run certain class of assembly instruction - generally the more privileged state will have the power to execute more instructions.
And one of the privileged instructions is to control the memory page table. And these various ring also give you kernel vs user-space execution threads.
- From (1), through page table mechanism, you will also have various types of memory: ring 0 or ring 3 memory.
Ring 0 will have more privilege, and store all your sensitive information - among them is your USERID information. If you are userid=0, you are privileged, and if not, then just a normal user. And every userid have different page tables in the kernel - which is why each process cannot modify each other memory directly. And remember the userid is stored in ring0 memory - your processes running in ring 3 will never be able to modify this info, and if you can , then you must have managed to escalate into the kernel to modify it ("privilege escalation").
To check whether you are root or non-root - do this in the kernel:
if (current_cred()->uid != 0)
And if you are not in the kernel - you have no access to all the credentials stored in the kernel. And one process cannot read another process memory - so no such check is needed if you are not in kernel, which can see ALL the memory for all process.
To sum it up: any processes you are running, which is always running at ring 3 privilege (for Intel), will have userid information kept in the kernel - which must have been originally created from another kernel component, or a root process (userid = 0). Any root-owned process (which is still running at ring3) will have capabilities (why? because it is written inside the Linux kernel source code itself:
https://stackoverflow.com/questions/15774548/check-for-user-root-within-linux-kernel) to transition into ring 0 privilege easily. This explained why no matter how you modify your own memory, (which is all running in ring 3) you will never be able to see/change your userid.
And you asked if ownership stored in files - yes files do contain userid ownership. And a running process (with a particular userid) cannot modify another files with a different userid. Security is compartmentalized this way in files + running processes (where userid is stored in kernel memory). But you cannot be fully assured that someone else cannot read your physical files.
If you can take the harddisk to another machine which you have root control, you can assume as ANY userid needed to read that particular userid-owned physical files on the harddisk. ie, if you does not have physical security, you can bypass all security mechanism on the harddisk, unless it is encrypted.