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
cgroups. A lot.
cgroups, 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 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
cgroup3, 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
cgroups 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
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
$pid is, again, the PID of the process in question.