Processos que diminuem os privilégios via setuid()
e setgid()
parecem não herdar as associações de grupo do uid / gid que eles definem.
Eu tenho um processo de servidor que deve ser executado como root para abrir uma porta privilegiada; depois disso, ele é redimensionado para um uid / gid não privilegiado específico, 1 - por exemplo, o do usuário foo
(UID 73). O usuário foo
é um membro do grupo bar
:
> cat /etc/group | grep bar
bar:x:54:foo
Portanto, se eu entrar como foo
, posso ler um arquivo /test.txt
com estas características:
> ls -l /test.txt
-rw-r----- 1 root bar 10 Mar 8 16:22 /test.txt
No entanto, o seguinte programa C (compilação std=gnu99
), quando executado root:
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
int main (void) {
setgid(73);
setuid(73);
int fd = open("/test.txt", O_RDONLY);
fprintf(stderr,"%d\n", fd);
return 0;
}
Sempre relata Permissão negada . Eu imagino que isso tenha a ver com ser um processo sem logon, mas meio que prejudica a maneira como as permissões devem funcionar.
1. O que geralmente é SOP para servidores, e acho que deve haver uma maneira de contornar isso, pois encontrei um relatório de alguém fazendo o apache - o apache foi adicionado ao grupo de áudio e, aparentemente, pode usar o sistema de som. Obviamente, isso provavelmente acontece em um fork e não no processo original, mas, na verdade, o caso é o mesmo no meu contexto (é um processo filho bifurcado após a chamada setuid).
setgid(54)
vez de setgid(73)
(como em /etc/groups
, group bar
has gid 54), isso funciona?
setuid()
novamente depois de fazê-lo ... mas, hmmm ... Eu acho que você pode com seteuid()
...
setuid()
/setgid()
chamadas.