a protection domain
Picture a hospital where staff wear color-coded badges. While you wear the blue badge you may enter the wards and the pharmacy but not the server room; swap to the red badge and a different set of doors opens. The badge does not change who you are — it changes the bundle of things you are currently allowed to do. A protection domain is exactly such a badge for running code: it is the set of access rights in force at a given moment, defining precisely which objects the code may touch and how.
More carefully, a protection domain is a collection of (object, rights) pairs. Each pair names a resource — a file, a region of memory, a device — and the operations permitted on it, such as read, write, or execute. At any instant, a process executes within exactly one domain and may perform only the operations its current domain grants. Crucially, a process is not welded to a single domain forever: it can switch domains. A classic example is a Unix program with the setuid bit — while it runs, it executes in the domain of the program's owner rather than the user who launched it, temporarily gaining (and being limited to) a different set of rights. The dual-mode user-versus-kernel split is itself a coarse two-domain scheme: user mode is one domain, kernel mode another with far more rights.
Why frame protection this way? Because the domain concept cleanly separates the question who am I right now from what may I do, and it lets the same code operate with different authority at different times. This is the foundation on which the access matrix, capabilities, and access-control lists are all built — they are just different ways of recording and enforcing exactly which (object, rights) pairs each domain holds. The honest subtlety is that domain switching is itself a privileged, dangerous operation: if a process could freely jump into a more powerful domain, the whole protection scheme would collapse, so the rules for changing domains must be enforced as carefully as the rights within them.
The Unix passwd program is owned by root and has the setuid bit set. When an ordinary user runs it to change their password, the process executes in root's domain so it can write the protected password file — but only through passwd's own carefully written code, which is itself restricted to that one task.
setuid lets a process run in another principal's domain for a bounded task.
A protection domain is about the code's current rights, not the user's identity directly — the same user can run in different domains at different moments, and the same domain can be entered by different users.