Processus qui désescaladent les privilèges via setuid()
et setgid()
ne semblent pas hériter des appartenances aux groupes de l'uid / gid qu'ils ont définis.
J'ai un processus serveur qui doit être exécuté en tant que root pour ouvrir un port privilégié; après cela, il désescalade en un uid / gid spécifique non privilégié, 1 - par exemple, celui de l'utilisateur foo
(UID 73). L'utilisateur foo
est membre du groupe bar
:
> cat /etc/group | grep bar
bar:x:54:foo
Donc, si je me connecte en tant que foo
, je peux lire un fichier /test.txt
avec ces caractéristiques:
> ls -l /test.txt
-rw-r----- 1 root bar 10 Mar 8 16:22 /test.txt
Cependant, le programme C suivant (compilation std=gnu99
), lors de l'exécution 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;
}
Signale toujours l' autorisation refusée . J'imagine que cela a à voir avec le fait qu'il ne s'agit pas d'un processus de connexion, mais cela gêne en quelque sorte la façon dont les autorisations sont censées fonctionner.
1. Ce qui est souvent SOP pour les serveurs, et je pense qu'il doit y avoir un moyen de contourner cela car j'ai trouvé un rapport de quelqu'un le faisant avec apache - apache a été ajouté au groupe audio et peut apparemment utiliser le système audio. Bien sûr, cela se produit probablement dans un fork et non dans le processus d'origine, mais en fait, le cas est le même dans mon contexte (c'est un processus enfant forké après l'appel de setuid).
setgid(54)
au lieu de setgid(73)
(comme dans /etc/groups
, le groupe bar
a gid 54), cela fonctionne-t-il?
setuid()
recommencer après l'avoir fait ... mais, hmmm ... je pense que vous pouvez avec seteuid()
...
setuid()
/setgid()
appels autour.