Em vez disso, ele inicia um novo processo shell com o novo ID do usuário. O shell original é bloqueado até que o novo shell seja concluído e o su saia. Por que isso funciona assim?
Simples: porque não pode. Não há chamada de sistema para alterar o fluxo de outro processo. Se você não quiser deixar o shell pai esperando que su saia, prefixe-o com o comando exec builtin, o que faz com que o shell seja executado diretamente sem forjar primeiro. Claro que se você errar a senha, não haverá shell para retornar, então sua sessão terminará.
Como foi apontado, não há como fazê-lo. Claro, se houver um testamento, existe uma maneira: que não existe tal syscall não é motivo para que ele não possa ser feito. Dito isto, como o mtk mencionou em um comentário , imagine o caos que ele poderia criar tendo um syscall para alterar o contexto de segurança de um processo não relacionado. Se nada mais, eu vejo uma condição de corrida irrompendo em três ... dois ... um ... (e não vamos sequer começar o que mudar o contexto de segurança de init ou getty poderia fazer.)
Uma outra razão é que su não só invoca um novo shell . Ele também tem a capacidade de controlar qual shell é lançado (usando -s ou --shell ) e controlá-lo passando parâmetros via (no GNU) o - / -l / --login e -c ( --command ) parâmetros. Os parâmetros passados para o su também podem ter um efeito no ambiente do novo shell. Assim, mesmo que você pudesse apenas alterar o contexto de segurança do processo pai, você não necessariamente desejaria fazer isso.
Tags su