Procesy, które zmniejszają uprawnienia za pośrednictwem setuid()
i setgid()
nie wydają się dziedziczyć członkostwa w grupach ustawionego identyfikatora UID / GID.
Mam proces serwera, który należy wykonać jako root, aby otworzyć uprzywilejowany port; potem następuje eskalacja do konkretnego nieuprzywilejowanego identyfikatora UID / gid, 1 - np. użytkownika foo
(UID 73). Użytkownik foo
jest członkiem grupy bar
:
> cat /etc/group | grep bar
bar:x:54:foo
Dlatego jeśli zaloguję się jako foo
, mogę odczytać plik /test.txt
o następujących cechach:
> ls -l /test.txt
-rw-r----- 1 root bar 10 Mar 8 16:22 /test.txt
Jednak następujący program C (kompilacja std=gnu99
) po uruchomieniu roota:
#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;
}
Zawsze zgłasza odmowę dostępu . Wyobrażam sobie, że ma to związek z tym, że jest to proces bez logowania, ale to rodzaj ścięgien w sposób, w jaki powinny działać uprawnienia.
1. Który często jest SOP dla serwerów, i myślę, że musi być jakiś sposób na obejście tego, ponieważ znalazłem raport o tym, że ktoś robi to z apache - apache został dodany do grupy audio i najwyraźniej może następnie użyć systemu dźwiękowego. Oczywiście dzieje się tak prawdopodobnie w rozwidleniu, a nie w oryginalnym procesie, ale w rzeczywistości sprawa jest taka sama w moim kontekście (jest to proces potomny rozwidlony po wywołaniu setuid).
setgid(54)
zamiast setgid(73)
(jak w /etc/groups
, grupa bar
ma gid 54), czy to działa?
setuid()
ponownie po tym, jak to zrobisz ... ale, hmmm ... Myślę, że możesz z seteuid()
...
setuid()
/setgid()
wywołuje.