SETUID / SETGID em um executável binário parou de funcionar após a atualização do Fedora Core

Question

Eu tenho um programa em C que precisa acessar um diretório protegido cheio de coisas. texto strong A idéia é que apenas o programa ou o administrador tenham acesso.

No passado, em plataformas Linux, usei os bits SETUID e SETGID do sistema de arquivos com bastante êxito. O programa é executado bem, seja qual for o UID e o GID que o sistema de arquivos diz ser o proprietário do executável, não importa quem o execute.

Em vez disso, costumava ser executado com sucesso.

Eu não sei exatamente quando essa mudança ocorreu porque eu só tento atualizar o sistema operacional quando há uma falha de hardware, então eu recebo as duas atualizações de uma só vez ... Então, dado muitas versões são ignoradas, eu, só que a partir de agora, o sistema de desenvolvimento que está no Fedora Core 17 não está mais honrando esses bits. Como o FC 19 é o lançamento atual, imagino que as coisas só são piores com o lançamento mais recente, não melhor.

Aqui está a saída 'ls -l':

-rwsrwsr-x 1 cu cu 26403 Aug 28  2012 comp

Ao investigar uma solução, encontrei a man page de chmod que diz isso:

Additional restrictions may cause the set-user-ID and set-group-ID bits of MODE or RFILE to be ignored. This behavior depends on the policy and functionality of the underlying chmod system call. When in doubt, check the underlying system behavior.

OK, mas não tenho IDEA como verificar essa política e funcionalidade como sugerido! Eles não ofereceram nenhuma ajuda a não ser usar o comando info - mas não achei nada útil, apenas dados sobre o usuário padrão e a propriedade do grupo para a criação de novos arquivos.

O SELINUX está desativado.

Perguntas:

1. Qual é a maneira "correta" de fazer esse tipo de coisa no mundo moderno? era?

2. Como faço para verificar as políticas e alterá-las?

Obrigado por qualquer entrada.

MAIS DADOS:

O programa C simplesmente tem essa linha que está ramificando para gerar um erro - um trecho:

  line=malloc(large);
  if (!line) printf("virtual memory exhausted\n");
  if (line && FileExists(filename))
  {
     if (access(filename,R_OK)==0)
     {
        cfile=fopen(filename, "r");

    

Answer 1

O problema no seu caso é o uso de access() .

A página man 2 access diz:

  The check is done using the calling process's real UID and GID,  rather
  than the effective IDs as is done when actually attempting an operation
  (e.g., open(2)) on the file.  This allows set-user-ID programs to  eas‐
  ily determine the invoking user's authority.

Quando você executa com binários setuid, você só altera seu UID efetivo e não o seu real. Portanto, a chamada access() sempre falhará.

Você deve remover o access() . É redundante neste caso, já que você usa o fopen para abrir o arquivo de qualquer maneira, também é muito difícil executar uma verificação de acesso como essa e, em seguida, executar uma leitura nele.