They both seem to me to create a login session for target-user.
Na realidade, eles não. su não cria uma sessão de login. Ele "alterna usuário" para executar um programa sob a égide de uma conta de usuário diferente, adicionando privilégios (os privilégios dessa conta) à totalidade de privilégios disponíveis para o usuário da sessão de login existente que é executada em.
Na verdade, o programa login não cria uma sessão de login . Ele espera que a sessão de login, com o processo executando login marcado como o processo líder da sessão e um terminal de controle anexado, já tenha sido configurado por qualquer que tenha sido chamado. login target-user , assumindo que o comando login embutido do shell C é efetivamente um exec , coopta a sessão de login já configurada existente para outra conta de usuário. Isto, obviamente, envolve riscos que são bem conhecidos por este ponto.
Isto, é claro, considerando o conceito do kernel de uma sessão de login , que envolve um líder de sessão , um terminal de controle e grupos de processos . O pessoal do sistema inventou seu próprio conceito de modo de aplicativo de uma sessão de login, gerenciada por systemd-logind em conjunto com os plug-ins do PAM. As regras são um pouco diferentes aqui, em parte porque as pessoas do systemd as alteraram combinando a parada do serviço no desligamento com a interrupção da sessão (e ainda precisam corrigir isso). Mas su não cria esse tipo de sessão de login.
Leitura adicional
- Jonathan de Boyne Pollard (2014). Não abuse do su para eliminar privilégios de usuário . Respostas frequentemente dadas.
- link
- Como o processo (sd-pam) se livra do unpraveged 'pam_session_close ()'?
- Qual é a diferença entre pam_unix e pam_systemd?
- Qual serviço do systemd inicia o console de texto no dispositivo framebuffer?
- Jonathan de Boyne Pollard (2016-06-01). Re: systemd elimina os processos em segundo plano depois que o usuário faz logout . Bug do Debian # 825394.