O systemd é um sistema de inicialização novo (tem cerca de 4 anos, eu acredito). No entanto, o systemd abrange muito mais do que o PID 1. Especificamente, ele inclui um substituto para o ConsoleKit, o software antigo que gerenciava as sessões do TTY, as sessões do X11 e, na verdade, apenas os logins em geral. O substituto do systemd para o ConsoleKit é chamado de logind e tem várias vantagens (por exemplo, o multi-seat é finalmente possível, outras coisas das quais eu não tenho certeza, etc.).
Agora, systemd < 3 cgroup s. Um lote . cgroup s, também conhecido como Process Control Groups, é como o systemd monitora quais processos pertencem a qual "serviço" abstrato 1 . A chave para entender sua pergunta é que logind faz isso também para os usuários: cada sessão de usuário recebe sua própria "sessão" de kernel, que é apoiada por - você adivinhou - um cgroup . Por quê? Porque então o kernel é capaz de gerenciar recursos apropriadamente entre usuários. Só porque um usuário está executando muitos processos, não significa que deva obter mais tempo de CPU. Mas com cgroup s, cada cgroup recebe tempo igual no processador e, portanto, cada usuário obtém recursos iguais.
Ok, agora terminamos com o plano de fundo. Pronto? A resposta real à sua pergunta é extremamente não dramática, dado o acúmulo acima: o processo "dono" corresponde a quem iniciou o processo, não importa o que aconteça. Em um nível técnico, isso é acompanhado por uma sessão de usuário, apoiada por um cgroup . O processo "usuário" é o sentido tradicional de "usuário": a identidade na qual o processo está sendo executado (e tudo o que está associado a essa identidade, principalmente as permissões).
Veja um exemplo: você faz login no GNOME e inicia um terminal. O processo que está executando o GNOME Shell e o GNOME Terminal e gnome-session e tudo o mais que compõe o GNOME está sendo executado como user: you (porque você forneceu suas credenciais e logado) e é de sua propriedade também (porque foi seu falha, por assim dizer, que os processos foram iniciados). Agora, digamos que você sudo -u ex. %código%. Agora você está executando um processo que assumiu a identidade de nobody , mas em um nível abstrato mais alto, o processo ainda foi iniciado por você e ainda está anexado à sua sessão 2 . Este nível é controlado pelo seu usuário nobody 3 , e é isso que determina o fato de você ser o "proprietário".
1 : pegue o Apache, por exemplo. Quando o Apache é iniciado, ele possui um processo principal para controlar tudo, mas também gera vários subprocessos. O processo principal do Apache na verdade não faz nenhum trabalho: ele apenas direciona os subprocessos, e os processos são aqueles que fazem todo o trabalho. (Isso é feito dessa forma por vários motivos.) O fato de que o conceito abstrato do "serviço" do Apache não pode ser mapeado diretamente para um conceito concreto do "processo" do Apache cria problemas para gerenciadores de serviço como o systemd. É aqui que entram cgroup s: o processo Apache original e principal é colocado em um Grupo de Controle e, não importa o que ele faça, ele não pode sempre escapar desse cgroup . Isso significa que o conceito abstrato do serviço Apache agora pode ser mapeado diretamente para o conceito concreto do "Apache cgroup ".
2 : veja cgroup para obter algumas informações sobre a sessão do kernel de um processo, onde /proc/$pid/sessionid é o PID do processo em questão.
3 : você pode encontrar mais informações sobre o processo ' $pid dando uma olhada em cgroup , onde /proc/$pid/cgroup é, novamente, o PID do processo em questão.
