the user/group IDs and process credentials
When a process tries to open a file, kill another process, or change a system setting, the operating system has to decide: is this allowed? It answers by looking at who the process is acting as. A process does not have a username; it has numeric credentials - a user ID (UID) and one or more group IDs (GIDs) - that say which account's authority it carries. These numbers are the process's identity badge, and the kernel checks them on every permission decision. Think of an ID badge that opens some doors and not others.
The details are a little richer than one number. Each process actually has a real UID (who started it / who owns it) and an effective UID (the identity used right now for permission checks), plus the same pair for groups, and a supplementary group list. Usually real and effective match. They differ in one important case: a set-user-ID (setuid) program. If an executable file has the setuid bit set and is owned by, say, root, then when you run it your process gets your real UID but root's effective UID - it temporarily acts with root's authority for the duration. The classic example is passwd: an ordinary user runs it, but it must edit a root-owned password file, so it runs setuid-root. Critically, credentials are inherited across fork() (the child gets the parent's UIDs/GIDs) and survive exec() unless the new program file is setuid; this is how a daemon that drops to an unprivileged user stays unprivileged for everything it launches.
Why it matters: process credentials are the foundation of all Unix permission and security. They decide which files you can read, whose processes you can signal, and what privileged operations the kernel will allow. The real-versus-effective distinction is the basis of privilege escalation done right (and the source of nasty bugs done wrong): a careful program raises its effective privilege only for the brief operation that needs it and drops it immediately, while a careless setuid program is a favorite target for attackers. Even if you only ever write ordinary code, knowing your process runs as some UID/GID explains every 'Permission denied' you will ever hit.
Run id and it prints your process's credentials: uid=1000(alice) gid=1000(alice) groups=1000(alice),27(sudo). Run ls -l /usr/bin/passwd and you see -rwsr-xr-x with an s where an x would be: that s is the setuid bit, so passwd runs with root's effective UID even when alice launches it.
id shows a process's UID/GID; the setuid bit (s) lets a program run with the file owner's effective UID.
Credentials are inherited across fork and survive exec (unless the new file is setuid). A daemon that drops privileges before forking workers keeps those workers unprivileged - a deliberate, important security move.