Qual é o caso de “um processo em execução com o processo de privilégios extras pode ser utilizado”?

Question

De link

The kernel view

Conceptually, there are three sets of groups that a process is a member of. Each set is a subset of the following one.

1. The single group that is the process's default group, which files created by this process will belong to.
2. The set of groups that are checked when the group requires permission to open a file.
3. The set of groups that a process running with extra privileges process can draw upon.

For historical reasons, these sets are respectively:

1. the effective group ID (egid);
2. the effective group ID plus the supplementary group IDs;
3. all of the above plus the real group ID and the saved set-group-ID.

Perguntas:

1. Qual é o caso de "um processo em execução com o processo de privilégios extras pode ser utilizado" no ponto 3?

   Este caso é diferente do caso de "quando o grupo requer permissão para abrir um arquivo" no ponto 2?

2. Os "IDs de grupo suplementares" incluem o ID do grupo primário, em geral e no ponto 2, respectivamente?

   Por "em geral", quero dizer que a saída de id inclui os grupos primário e suplementar seguindo groups= , enquanto link diz" cada usuário pode pertencer a um número de grupos suplementares - e estes são listados no final de id output. " Então, eu me pergunto se o grupo primário também é um grupo suplementar?

Obrigado.

    

Answer 1

1. No Linux especificamente, hoje em dia, um “processo em execução com o processo de privilégios extras pode ser utilizado” é um processo que " tem o recurso CAP_SETGID em seu namespace de usuário ".

   Note que a introdução dos três pontos afirma que “cada conjunto é um subconjunto do seguinte”, então sim, o conjunto descrito no ponto 3 é diferente, conceitualmente, do conjunto descrito no ponto 2.

2. id imprime o grupo efetivo , não o grupo principal; você pode alterar seu grupo efetivo usando newgrp . O grupo primário é o grupo real / efetivo padrão. No Linux, getgroups ’manpage menciona que“ não é especificado se o    O ID de grupo efetivo do processo de chamada está incluído no    lista ", para que os grupos suplementares não incluam necessariamente o grupo principal.

Ainda considerando especificamente o Linux, vale a pena ler a a credentials manpage .

    

Answer 2

Dado o número de conceitos diferentes, acho mais fácil aprender com exemplos práticos.

Programas como o servidor NFS do espaço do usuário agem em nome de um usuário específico conectado pela rede. Eles alteram temporariamente seus IDs efetivos de usuário e grupo, por exemplo, ao abrir um arquivo em nome de um usuário específico. Eles podem voltar, porque ainda têm o UID e o GID privilegiados em seu UID e GID "salvos" ou "reais".

Eu aprendi recentemente que fusermount é outro exemplo de um programa que faz isso. Deve ser a raiz do set-uid para que possa montar sistemas de arquivos, mas deseja executar verificações de permissão como o usuário original, por exemplo, ao ler arquivos de configuração e ao atingir o diretório que é passado como um ponto de montagem. Pelo menos, deve mudar seu UID assim. Se este programa também fosse set-gid, então também teria que mudar seu GID. fusermount não precisa ser instalado como set-gid, mas o código altera seu GID efetivo de qualquer maneira. Não é preciso muito mais código e, pelo menos, espero que não cause problemas: -).

A página man de setfsgid() menciona este exemplo quando diz

Explicit calls to setfsuid() and setfsgid() are usually used only by programs such as the Linux NFS server that need to change what user and group ID is used for file access without a corresponding change in the real and effective user and group IDs

[...]

The filesystem user ID attribute was added to allow a process to change its user ID for the purposes of file permis‐ sion checking without at the same time becoming vulnerable to receiving unwanted signals. Since Linux 2.0, signal permission handling is dif‐ ferent (see kill(2)), with the result that a process change can change its effective user ID without being vulnerable to receiving signals from unwanted processes. Thus, setfsuid() is nowadays unneeded and should be avoided in new applications (likewise for setfsgid(2)).

i.e. as versões atuais desses programas alterarão temporariamente seu UID e GID efetivo, usando setresuid () e setresgid ().