Significado de setgid em um executável

Question

Eu recebo que setuid em um executável binário permite que o processo obtenha o uid efetivo do proprietário do binário. O que não consigo entender é se setuid bit está desativado, mas setgid bit está ativado para um executável específico. O que acontece nesse caso?

Exemplo: Suponha que tenhamos as seguintes permissões

ls -l my_bin
r-xr-s--- root wheel my_bin

Agora, suponha que o usuário userA seja um membro do grupo wheel . O que acontece quando userA tenta executar este programa?

Estou pensando que o ID de usuário efetivo deste processo se tornará o mesmo que uid para o usuário com o nome wheel . É um exemplo artificial, mas estou confuso com a forma como os direitos de grupo alteram o fluxo efetivo ou se eles têm algum impacto sobre o fluxo efetivo.

    

Answer 1

O bit setgid funciona da mesma forma que o bit setuid, mas para o ID do grupo. Assim, o processo será executado com um ID de roda group eficaz. O ID efetivo (e real) do usuário ainda será o do usuário que iniciou o programa.

A participação do usuário nesse grupo não importa de uma forma ou de outra.

edit: exemplo de programa C, para que você possa brincar com o funcionamento dele. Não é portátil, mas é trivial adotar para outro sistema:

#define _GNU_SOURCE
#include <stdio.h>
#include <unistd.h>

int main() {
    int ruid, euid, suid;
    int rgid, egid, sgid;

    if (0 != getresuid(&ruid, &euid, &suid)) {
        perror("getresuid");
        return 1;
    }
    if (0 != getresgid(&rgid, &egid, &sgid)) {
        perror("getresgid");
        return 1;
    }
    printf("ruid = %i, euid = %i, suid = %i\nrgid = %i, egid = %i, sgid = %i\n",
            ruid, euid, suid, rgid, egid, sgid);
    return 0;
}

    

Answer 2

O bit setgid também pode ser usado em diretórios. Se um diretório tiver o bit setgid e for gravável em grupo, se um usuário (não o proprietário do diretório) com um grupo primário diferente gravar um arquivo nesse diretório e tiver uma associação suplementar no grupo que possui o diretório, o novo arquivo obterá o grupo. mesma propriedade de grupo que o diretório. Não é o grupo principal do usuário que está gravando o arquivo. Muito útil em alguns casos.

Como exemplo, temos dois usuários, foo e bar. O grupo primário de foo também é foo. O grupo primário da barra é bar, mas é um membro suplementar da foo.

foo@valhalla:~$ id
uid=1002(foo) gid=1002(foo) groups=1002(foo)

bar@valhalla:~$ id
uid=1003(bar) gid=1003(bar) groups=1003(bar),1002(foo)

foo@valhalla:~$ grep foo /etc/group
foo:x:1002:bar
foo@valhalla:~$ grep bar /etc/group
foo:x:1002:bar
bar:x:1003:

Vou criar um diretório / tmp / foodir e torná-lo setgid e group writable.

foo@valhalla:~$ mkdir /tmp/foodir
foo@valhalla:~$ chmod g+ws /tmp/foodir
foo@valhalla:~$ ls -ld /tmp/foodir
drwxrwsr-x 2 foo foo 4096 Jun  6 19:30 /tmp/foodir

Agora vou tocar em um arquivo em / tmp / foodir como a barra de usuário.

bar@valhalla:~$ touch /tmp/foodir/barfile
bar@valhalla:~$ ls -l /tmp/foodir/barfile 
-rw-r--r-- 1 bar foo 0 Jun  6 19:32 /tmp/foodir/barfile

Observe que a propriedade de grupo de / tmp / foodir / barfile é foo, não bar, que é o grupo primário da barra de usuários.

Agora tentamos o contrário, mas foo não é membro da barra de grupo.

bar@valhalla:~$ mkdir /tmp/bardir
bar@valhalla:~$ chmod g+ws /tmp/bardir
bar@valhalla:~$ ls -ld /tmp/bardir
drwxrwsr-x 2 bar bar 4096 Jun  6 19:34 /tmp/bardir

Veja o que acontece quando tentamos tocar um arquivo como foo. É o que você deve esperar, um erro de permissão.

foo@valhalla:~$ touch /tmp/bardir/foofile
touch: cannot touch '/tmp/bardir/foofile': Permission denied

E para um último passo. Vamos tocar em um arquivo em / tmp (um diretório não setgid para o qual a barra pode gravar) como barra.

 bar@valhalla:~$ ls -ld /tmp/barfile
-rw-r--r-- 1 bar bar 0 Jun  6 19:36 /tmp/barfile

O proprietário e o grupo são ambos bar.