por que precisamos da permissão SUID? [fechado]

Ambos os seus exemplos explicam como funciona o setuid. No entanto, em seu "Linux ideal", cada executável começaria com EUID do proprietário do executável, o que tornaria cada executável em seu sistema um executável setuid.

Isso claramente causaria muitos problemas, para mencionar alguns: todo executável de propriedade de root precisaria fazer verificações de UID e chamar setuid()para definir o EUID do processo de volta para não-raiz se o programa não devesse ter nenhum privilégio adicional; os usuários não podem disponibilizar executáveis ​​para outros usuários, pois o processo seria executado com EUID errado; erros de configuração e más práticas teriam consequências críticas (como chmod 777agora também permitiria o acesso a quaisquer arquivos de propriedade do usuário). E estes são mais.

Permissões normais sem binários setuid precisam de algum outro mecanismo para permitir que usuários sem privilégios façam operações privilegiadas. Os binários setuid permitem tal elevação de privilégios e o controle de acesso é implementado na lógica do programa.

A resposta marcada respondeu perfeitamente à minha pergunta. O que coloco aqui é a lógica extra que me é útil para explicar a existência da permissão SUID em relação ao cenário de alteração de senha.

1. No Linux, os arquivos bin executáveis ​​devem ser executados por diferentes usuários.

   Por exemplo, /usr/bin/nanoé um bin para um editor de texto, faz sentido que esse mesmo arquivo bin executável possa ser executado por diferentes usuários (por que fazer cópias do mesmo arquivo bin para o sistema de arquivos inicial de cada usuário?)

2. Embora muitos usuários possam usar o mesmo arquivo bin, o processo iniciado por esse arquivo bin deve ter permissões diferentes em um arquivo.

   Por exemplo, userA e userB devem ser capazes de criar dois nanoprocessos executando o mesmo /usr/bin/nanoarquivo bin. No entanto, o processo nano do userA deve permitir que o userA modifique seus próprios arquivos e apenas seus próprios arquivos e vice-versa.

Isso exige um mecanismo pelo qual um processo deve aplicar a mesma permissão que o usuário que iniciou esse processo tem em um arquivo para esse arquivo ( em vez da permissão do usuário que possui o arquivo bin executável que foi executado para criar o processo) .

No Linux, cada processo tem o RUID . O RUID é o id do usuário que inicia esse processo. Por essa lógica, o RUID de um processo deve ser o usuário cuja permissão em um arquivo é usada por esse processo (por exemplo, um processo decide o que pode fazer com um arquivo com base no que seu usuário RUID pode fazer com esse arquivo).

No entanto, no caso de alterar a senha, o RUID por si só não é suficiente porque:

1. /etc/shadowarquivo não pode ser modificado por ninguém além de root .
2. Qualquer usuário que queira alterar a senha precisa fazer isso através da execução do /usr/bin/passwdarquivo bin executável. A lógica deste programa garante que um usuário desprivilegiado possa alterar sua e somente sua senha.
3. Nenhum usuário, exceto o root, pode alterar essa lógica, pois somente o root pode gravar nesse arquivo bin.
4. Se userA for executado /usr/bin/passwd, ele iniciará um passwd processo cujo RUID é userA .
5. No entanto, como o usuárioA não tem permissão para gravar em /etc/shadow, o passwd processo que ele inicia também não pode gravar nesse arquivo.

Isso exige um mecanismo pelo qual um processo decide suas permissões para um arquivo com base nas permissões de outro usuário nesse arquivo ( em vez das permissões do usuário que iniciou o processo ).

No Linux, a permissão que um processo tem em um arquivo é obtida da permissão que o EUID tem nesse arquivo.

Com o EUID , o root agora pode usar a permissão SUID para permitir que o usuárioA inicie um passwd processo que tenha o EUID definido como root . Isso efetivamente permite que o passwd processo iniciado pelo usuário A modifique o /etc/shadowarquivo.