systemd is a brand-spanking-new init system (it's about 4 years old, I believe). However, systemd encompasses much more than PID 1. Specifically, it happens to include a replacement for ConsoleKit, the old software that managed TTY sessions, X11 sessions, and really just logins in general. systemd's replacement for ConsoleKit is called logind, and has a number of advantages (e.g. multi-seat is finally possible, other things that I'm not really sure about, etc.).
Now, systemd <3 cgroup
s. A lot. cgroup
s, aka process Control Groups, are how systemd keeps track of what processes belong to which abstract "service"1. The key to understanding your question is that logind
does this for users too: each user session gets its own kernel "session", which is backed by - you guessed it - a cgroup
. Why? Because then the kernel is able to manage resources appropriately among users. Just because one user is running a lot of processes doesn't mean she should get more CPU time. But with cgroup
s, each cgroup
gets equal time on the processor, and so every user gets equal resources.
Okay, now we're done with the background. Ready? The actual answer to your question is extremely undramatic given the above build-up: the process "owner" corresponds to whoever started the process, no matter what. On a technical level, this is kept track of by a user session, backed by a cgroup
. The process "user" is the traditional sense of "user": the identity that the process is running under (and everything that is associated with that identity, most notably permissions).
Here's an example: you log into GNOME and start a terminal. The process that's running GNOME Shell and GNOME Terminal and gnome-session
and everything else that makes up GNOME is running as user: you (because you've provided your credentials and logged on) and it's owned by you, too (because it was your fault, so to speak, that the processes got started). Now let's say you sudo -u
to e.g. nobody
. You are now running a process that has assumed the identity of nobody
, but at a higher, abstract level, the process was still started by you and it's still attached to your session2. This level is kept track of by your user cgroup
3, and that's what determines the fact that you are the "owner".
1: take Apache, for example. When Apache starts up, it has one main process to control everything, but it also spawns a bunch of subprocesses. The main Apache process doesn't actually do any work: it just directs the subprocesses, and those processes are the ones that do all the work. (It's done this way for various reasons.) The fact that the abstract concept of the Apache "service" cannot be directly mapped to a concrete concept of "the" Apache process creates problems for service managers like systemd. This is where cgroup
s come in: the main, original Apache process is placed into a Control Group, and then no matter what it does, it cannot ever escape that cgroup
. This means that the abstract concept of the Apache service can now be directly mapped to the concrete concept of the "Apache cgroup
".
2: look at /proc/$pid/sessionid
to get some information about a process' kernel session, where $pid
is the PID of the process in question.
3: you can find out more information about a process' cgroup
by taking a peek at /proc/$pid/cgroup
, where $pid
is, again, the PID of the process in question.