Gnome's system monitor has a "User" column in the Processes tab. There's also an "Owner" column, (that seems to be hidden by default).
Most of the processes have the same values on both columns. However, a few don't.
I was wondering what exactly does each column show, and what's the difference between the two.
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 cgroups, 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 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 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.
The "Owner" column has to do with the username that owns the session that this particular process is a member of.
excerpt - The Linux kernel
10.3 Sessions
Every process group is in a unique session. (When the process is created, it becomes a member of the session of its parent.) By convention, the session ID of a session equals the process ID of the first member of the session, called the session leader. A process finds the ID of its session using the system call
getsid().Every session may have a controlling
tty, that then also is called the controlling tty of each of its member processes. A file descriptor for the controlling tty is obtained by opening/dev/tty. (And when that fails, there was no controllingtty.) Given a file descriptor for the controllingtty, one may obtain the SID usingtcgetsid(fd).A session is often set up by a login process. The terminal on which one is logged in then becomes the controlling tty of the session. All processes that are descendants of the login process will in general be members of the session.
This would be the "Session" column. The owner of this session ID is the "Owner" column.
Running GNOME system monitor, gnome-system-monitor from a shell:
