Unix / Linux: diferença entre ID de usuário real, ID de usuário efetivo e ID de usuário salvo

Já estou ciente da identidade do usuário real . É o número exclusivo de um usuário no sistema.

No meu sistema, meu uidé

$ echo $UID
1014
$                 

Quais são as outras duas representações de ID?
E qual é o uso de ID de usuário efetivo e ID de usuário salvo e onde nós os usamos no sistema?

A distinção entre uma identidade de usuário real e uma efetiva é feita porque você pode ter a necessidade de obter temporariamente a identidade de outro usuário (na maioria das vezes, isso seria root, mas poderia ser qualquer usuário). Se você tivesse apenas um ID de usuário, não haveria maneira de voltar ao seu ID de usuário original posteriormente (a não ser tomar sua palavra como certa, e caso tenha root, usar rootos privilégios de para mudar para qualquer usuário).

Então, o id de usuário real é quem você realmente é (aquele que possui o processo), e o id de usuário efetivo é o que o sistema operacional analisa para tomar uma decisão se você tem permissão ou não para fazer algo (na maioria das vezes , existem algumas exceções).

Quando você faz o login, o shell de login define o id de usuário real e efetivo com o mesmo valor (seu id de usuário real) conforme fornecido pelo arquivo de senha.

Agora, também acontece que você executa um programa setuid e, além de ser executado como outro usuário (por exemplo root), o programa setuid também deve fazer algo em seu nome. Como é que isso funciona?
Depois de executar o programa setuid, ele terá seu id real (já que você é o dono do processo) e o id de usuário efetivo do dono do arquivo (por exemplo root), uma vez que é setuid.

O programa faz toda a mágica necessária com os privilégios de superusuário e, em seguida, deseja fazer algo em seu nome. Isso significa que tentar fazer algo que você não deveria ser capaz de fazer falhar . Como isso faz? Bem, obviamente, alterando seu id de usuário efetivo para o id de usuário real!

Agora, aquele programa setuid não tem como voltar atrás já que tudo que o kernel conhece é o seu id e ... seu id . Bang, você está morto.

É para isso que serve o set-user id salvo.

Vou tentar explicar passo a passo com alguns exemplos.

Fundo curto

Cada processo tem suas próprias 'credenciais processo' que inclui atributos como PID, os PPID, PGID, session IDe também os IDs de usuário e grupo reais e eficazes: RUID, EUID, RGID, EGID.

Vamos nos concentrar nisso.

Parte 1: Compreender UID e GID

Agora, vou entrar em um shell com minhas credenciais e executar:

$ grep $LOGNAME /etc/passwd
rotem:x:1000:1000:rotem,,,:/home/rotem:/bin/bash

Você pode ver meu nome de log (rotem), o UID e GID que são 1000 e outros detalhes como o shell em que estou conectado.

Parte 2: Entenda RUID e RGID

Todo processo tem um dono e pertence a um grupo .
Em nosso shell, todos os processos que executaremos agora herdarão os privilégios da minha conta de usuário e serão executados com o mesmo UID e GID.

Vamos executar um comando simples para verificar:

$ sleep 10 & ps aux | grep 'sleep'

E verifique o UID e GID do processo:

$ stat -c "%u %g" /proc/$pid/
1000 1000

Esses são o ID do usuário real ( ) e o ID do grupo real ( ) do processo .RUIDRGID

(*) Marque outras opções para visualizar o UID e GID e maneiras de obtê-los em uma linha .

Por enquanto, aceite o fato de que os atributos EUIDe EGIDsão 'redundantes' e são iguais a RUIDe RGIDnos bastidores.

Parte 3: Compreender EUID e EGID

Vamos tomar o pingcomando como exemplo.

Procure o local binário com o whichcomando e execute ls -la:

-rwsr-xr-x  1 root root   64424 Mar 10  2017  ping

Você pode ver que o proprietário e o grupo do arquivo são root. Isso ocorre porque o pingcomando precisa abrir um soquete e o kernel do Linux exige rootprivilégio para isso.

Mas como posso usar pingse não tenho rootprivilégios?
Observe a letra 's' em vez de 'x' na parte do proprietário da permissão do arquivo.
Este é um bit de permissão especial para arquivos binários executáveis ​​específicos (como pinge sudo) conhecido como setuid .

Isto é onde EUIDe EGIDentra em jogo.
O que acontecerá é que quando um binário setuid como é pingexecutado, o processo muda seu ID de usuário efetivo ( EUID) do padrão RUIDpara o proprietário deste arquivo executável binário especial que neste caso é -root .
Isso tudo é feito pelo simples fato de que esse arquivo tem a setuidbit.

O kernel toma a decisão se este processo tem o privilégio, observando o EUIDdo processo. Porque agora EUIDaponta para root, a operação não será rejeitada pelo kernel.

Aviso : Nos últimos lançamentos do Linux, a saída do pingcomando parecerá diferente devido ao fato de que eles adotaram a abordagem de recursos do Linux em vez desta abordagem setuid - para aqueles que não estão familiarizados - leia aqui .

Parte 4: E quanto a SUID e SGID?

O ID de usuário salvo ( SUID) está sendo usado quando um processo privilegiado está em execução (como rootpor exemplo) e precisa realizar algumas tarefas não privilegiadas.

Nesse caso, o UID ( EUID) efetivo anterior será salvo internamente SUIDe então alterado para uma tarefa sem privilégios. Quando a tarefa sem privilégios for concluída, o EUIDserá retirado do valor de SUIDe voltará para a conta com privilégios.