qual é o propósito do setuid habilitado sem nenhum bit executável?

Question

Estou tentando entender as permissões em detalhes. Eu estava lendo sobre setuid e é usos. No entanto, este caso particular me confunde.

Eu fiz um pequeno script e agora eu configurei o bit suid para o script como abaixo.

chmod u+s ramesh

Eu vejo as permissões definidas abaixo.

-rwsrw-r--  1 ramesh ramesh   29 Sep 30 10:09 ramesh

Agora, acredito que com o setuid, qualquer usuário poderia executar o script. Agora eu fiz o comando

chmod u-x ramesh

Isso me dá a permissão,

-rwSrw-r--  1 ramesh ramesh   29 Sep 30 10:09 ramesh

Agora, eu entendo que o S denota o setuid sem nenhum bit executável. Ou seja, ninguém pode executar este arquivo.

Então, minha pergunta é: que propósitos práticos a configuração de S bit tem? Eu estou tentando entender de uma perspectiva de exemplo para definir este bit.

    

Answer 1

Now, I believe with setuid any user could execute the script.

Não é bem assim. Para tornar o script executável por todos os usuários, você só precisa definir as permissões de + rx:

chmod a+rx script

setuid significa que o script é sempre executado com as permissões do proprietário , isto é, se você possui o seguinte binário:

martin@dogmeat ~ % touch dangerous
martin@dogmeat ~ % sudo chown root:root dangerous 
martin@dogmeat ~ % sudo chmod a+rx,u+s dangerous 
martin@dogmeat ~ % ll dangerous 
-rwsrwxr-x 1 root root 0 Sep 30 17:23 dangerous*

Este binário será sempre executado como root, independentemente do usuário que está executando. Obviamente, isso é perigoso e você precisa ser extremamente cuidadoso com o setuid, especialmente quando estiver escrevendo aplicativos setuid. Além disso, você não deveria estar usando setuid em scripts, pois é inerentemente inseguro no Linux.

Now, I understand the S denotes setuid with no executable bit. That is, no one can execute this file.

So my question is, what practical purposes do the setting of S bit have? I am trying to understand from an example perspective for setting this bit.

Eu não acho que haja um propósito prático, IMO é apenas uma combinação possível dos bits de permissão.

    

Answer 2

Todos os bits de permissão podem ser definidos ou apagados de forma independente. Algumas combinações são muito comuns, outras não servem a nenhum propósito prático. ls usa uma letra maiúscula S para indicar “ s sem x ” para destacar que essa é uma configuração estranha, possivelmente errônea.

Se um arquivo não é executável por ninguém, seus bits setuid e setgid não são relevantes. Lembre-se de que, mesmo que as permissões unix tradicionais do arquivo não tenham x bit definido, pode haver uma ACL que permita que alguns usuários ou grupos executem o arquivo.

Em muitas variantes Unix, incluindo Linux e Solaris, o bit setgid em um diretório controla se os arquivos criados nesse diretório herdam a ID de grupo do diretório (semântica BSD, usada quando o bit setgid é definido) ou o ID de grupo efetivo do processo ( Semântica do sistema V, usada quando o bit setgid é claro).

No Solaris, o bit setgid em um arquivo regular que não é executável ativa o bloqueio obrigatório. O bloqueio obrigatório permite bloqueios definidos pelo fcntl mecanismo de bloqueio para ser obrigatório, ou seja, se um processo tiver o bloqueio e outro processo não usar nenhum bloqueio, o segundo processo não poderá acessar o arquivo.

    

Answer 3

Uma finalidade de ter um arquivo não executável, mas setuid e / ou setgid, é usar uma lista de controle de acesso (ACL) para permitir que apenas determinados usuários executem esse arquivo. Se você quer rodar um comando com setuid root, mas, por exemplo, você não quer que todos possam rodar esse comando. Se você quiser que apenas alguns usuários ou determinados grupos possam executá-lo, você poderá proibir a execução em geral e permitir a execução limitada com uma ACL.

O exemplo a seguir usa um comando fictício e o torna geralmente não executável, mas setuid, em seguida, usa uma ACL para permitir que os membros do grupo adm o executem:

$ chown root.root privileged_command
$ chmod 4000 privileged_command
$ ls -l privileged_command
---S------ 1 root root 152104 Nov 17 21:15 privileged_command
$ setfacl -m g:adm:rx privileged_command

Assim, de acordo com as permissões do arquivo, o arquivo é setuid, mas não é executável (nem legível). No entanto, a lista de controle de acesso fornece privilégios de leitura e execução para todos os membros do grupo adm.

Se um membro do grupo adm executar o arquivo, ele executará com os privilégios setuid que o arquivo possui, sob os privilégios executáveis concedidos pela ACL. Se alguém tentar executá-lo, receberá um erro de permissão negada.

Fazendo uma listagem de diretório do arquivo após o comando setfacl acima será mostrado:

$ ls -l privileged_command
---Sr-x---+ 1 root     root     152104 Nov 17 21:15 privileged_command

Isso parece mostrar que o grupo raiz tem privilégios de leitura / execução no arquivo, mas na verdade está apenas indicando que há uma acl que fornece privilégios de leitura / execução.

Este é um exemplo de onde você pode querer ter um programa como setuid mas não (normalmente) executável.