☰

Por que os bits de modo S_ISUID e S_ISGID foram apagados quando o proprietário ou grupo de um arquivo executável é alterado por um usuário sem privilégios

tag-icon • tag-icon permissions executable chown setuid setgid
Por que os bits de modo S_ISUID e S_ISGID foram apagados quando o proprietário ou grupo de um arquivo executável é alterado por um usuário sem privilégios

Eu estava lendo a manpágina do chown. Não entendo por que S_ISUIDo S_ISGIDmodo deve ser desmarcado quando a função retorna com êxito.

Responder1

Acho que você está apontando para isso na página de manual:

Quando o proprietário ou grupo de um arquivo executável é alterado por um usuário sem privilégios, os bits de modo S_ISUID e S_ISGID são apagados.

Então, por que eles foram liberados agora? Você vê que eles só são liberados no caso de umexecutávelarquivo. Porque quando um dos bits (SUID/SGID) é definido, o usuário sem privilégios pode executar o arquivo como o novo proprietário do arquivo. Isso seria uma enorme violação de segurança.

Responder2

Acho que você leu errado man 2 chown:vocênão precisa limpar S_ISUIDe S_ISGID, eles serão limpos automaticamente quando você usar essa função como um usuário sem privilégios. Se o seu programa estiver rodando, rooto comportamento (no Linux) depende da versão do kernel.

Se você precisar dos bits definidos, basta reaplicá-los (assumindo que a conta que tenta defini-los tenha privilégios para fazê-lo).

Na página de manual:

  When  the  owner  or  group  of  an  executable file are changed by an
  unprivileged user the S_ISUID  and  S_ISGID  mode  bits  are  cleared.
  POSIX  does not specify whether this also should happen when root does
  the chown(); the Linux behavior depends on  the  kernel  version.   In
  case  of  a non-group-executable file (i.e., one for which the S_IXGRP
  bit is not set) the S_ISGID bit indicates mandatory  locking,  and  is
  not cleared by a chown().

informação relacionada