Korzystam z systemu stacjonarnego Ubuntu 12.04. Do tej pory zainstalowałem tylko niektóre programy (mam prawa sudo).

1. Kiedy sprawdzam listę użytkowników w systemie, widzę długą listę, na przykład ponad 20 użytkowników - kiedy ci użytkownicy zostali stworzeni (np. Demon, sys, synchronizacja, gry, puls itp.)? W jaki sposób są one związane z instalowaniem nowych programów?

2. Jeśli uruchomię program w moim systemie, powinien on działać z moim identyfikatorem UID. Ale podczas psowania widzę wiele innych programów działających z innym UID (takich jak root, daemon, avahi, syslog, colord itp.) - jak te programy zostały uruchomione z różnymi UID?

Konta użytkowników są używane nie tylko dla rzeczywistych, ludzkich użytkowników, ale także do uruchamiania usług systemowych, a niekiedy także jako właścicieli plików systemowych. Dzieje się tak, ponieważ rozdzielenie zasobów ludzkich użytkowników (procesów, plików itp.) I rozdzielenie zasobów usług systemowych wymaga tych samych mechanizmów pod maską.

Programy, które uruchamiasz zwykle działają z twoim identyfikatorem użytkownika. To tylko demony systemowe działające na ich własnym koncie. Plik konfiguracyjny wskazujący, kiedy uruchomić demona, wskazuje również, który użytkownik powinien go uruchomić, lub demon przełącza się na nieuprzywilejowane konto po uruchomieniu. Niektóre demony wymagają pełnych uprawnień administracyjnych, więc działają na koncie root . Wiele demonów potrzebuje dostępu tylko do określonego urządzenia sprzętowego lub do określonych plików, więc działają one na dedykowanym koncie użytkownika. Odbywa się to dla bezpieczeństwa: w ten sposób, nawet jeśli w jednej z tych usług występuje błąd lub błędna konfiguracja, nie może to prowadzić do pełnego ataku systemu, ponieważ atakujący będzie ograniczony do tego, co ta usługa może zrobić i nie będzie możliwość nadpisywania plików, szpiegowania procesów itp.

W systemie Ubuntu podczas instalacji systemu tworzone są identyfikatory użytkowników z zakresu 0–99. 0 oznacza root; wiele z tych w zakresie 1–99 istnieje tylko ze względów historycznych i jest przechowywanych tylko dla wstecznej kompatybilności z niektórymi lokalnymi instalacjami, które ich używają (kilka dodatkowych wpisów nie szkodzi). Identyfikatory użytkowników w zakresie 100–999 są tworzone i usuwane dynamicznie, gdy usługi wymagające dedykowanego identyfikatora użytkownika są instalowane lub usuwane. Zakres od 1000 jest przeznaczony dla użytkowników lub innych kont utworzonych przez administratora systemu. To samo dotyczy grup.

Zakładam, że znajdujesz tę listę użytkowników, sprawdzając /etc/passwd? Jest to całkowicie normalne - „użytkownicy” służą do przenoszenia zestawu uprawnień, przydatnych do blokowania nie tylko „rzeczywistych użytkowników”, ale także programów w określonych obszarach systemu i śledzenia zmian, które zmienili (ta sama koncepcja z grupami).

Wstawiłem jeden z moich /etc/passwdplików Raspberry Pi poniżej w celach informacyjnych; zauważysz użytkownika ntopna dole tego pliku, utworzonego przez program ntop(monitorowanie sieci). Podobnie sshd, gnatszgłaszanie błędów itp.

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
pi:x:1000:1000:,,,:/home/pi:/bin/bash
sshd:x:101:65534::/var/run/sshd:/usr/sbin/nologin
ntp:x:102:104::/home/ntp:/bin/false
statd:x:103:65534::/var/lib/nfs:/bin/false
messagebus:x:104:106::/var/run/dbus:/bin/false
usbmux:x:105:46:usbmux daemon,,,:/home/usbmux:/bin/false
lightdm:x:106:109:Light Display Manager:/var/lib/lightdm:/bin/false
smmta:x:107:110:Mail Transfer Agent,,,:/var/lib/sendmail:/bin/false
smmsp:x:108:111:Mail Submission Program,,,:/var/lib/sendmail:/bin/false
Debian-exim:x:109:113::/var/spool/exim4:/bin/false
ntop:x:110:115::/var/lib/ntop:/bin/false

Kiedy utworzono tych użytkowników?

W przypadkach, o których wspomniałeś, zostały one utworzone podczas instalacji systemu. Te konta użytkowników są konwencjonalne, niektóre sięgają dziesięcioleci. Są również znormalizowane. Linux Standard Base dzieli je na:

• wymagane rachunków standard obsługi, root, bin, i daemon; i
• opcjonalne standardowe konta użytkowników adm, lp, sync, shutdown, halt, mail, news, uucp, operator, man, inobody

Inne konta użytkownika, które są wymienione tutaj - pulse, avahi, colordoraz Debian-exim(aby wybrać jeden z pliku haseł py4on'S) - doprowadzi nas do następnego pytania.

W jaki sposób są one związane z instalowaniem nowych programów?

Niestandardowe konta użytkowników są tworzone i niszczone przez „skrypty opiekuna” dla różnych pakietów, ponieważ pakiety te są instalowane i usuwane. Konto użytkownika zostanie utworzone za pomocą tak zwanego postinstskryptu opiekuna pakietu , który uruchamia się, getentaby sprawdzić, czy konto użytkownika już istnieje, a useraddjeśli nie. Teoretycznie zostałby usunięty przez uruchomiony tak zwany postrmskrypt opiekuna pakietu userdel.

W praktyce konta użytkowników dla pakietów nie są usuwane. Wiki Fedory (qv) wyjaśnia, że ​​byłoby to trudne. Zobacz błąd Debiana # 646175, aby zobaczyć przykład takiego uzasadnienia w działaniu, w którym postanowiono po prostu nie usuwać rabbitmqkonta użytkownika po wyczyszczeniu pakietu, aby rozwiązać problem z demonem, który nadal działa pod egidą tego konta.

Jak te programy zostały uruchomione z różnymi identyfikatorami UID?

W systemach Unix i Linux proces działający pod egidą administratora może zmienić konto użytkownika na coś innego i kontynuować działanie tego samego programu, ale odwrotność nie jest dozwolona. (Należy użyć mechanizmu set-UID.)

System zarządzania dæmon działa jako administrator. Jego dane konfiguracyjne określają, że poszczególne demony działają pod egidą poszczególnych kont użytkowników:

• W systemie 5 rcskrypt /etc/init.dużywa narzędzia pomocniczego, takiego jak start-stop-daemoni jego --chuidopcji.
• Z menedżerem usług daemontools rodziny, runrozmowy skrypt setuidgid, s6-setuidgid, chpst, lub runuidz nazwą konta użytkownika. Istnieją tego przykłady w /unix//a/179798/5132, które ustawiają nagioskonto użytkownika.
• Przy wstępnym uruchomieniu setuidw pliku zadania znajduje się zwrotka określająca konto użytkownika. Nie jest to szczególnie drobnoziarniste i czasami chce się tego, co opisano na /superuser//a/723333/38062 .
• W systemd znajduje się User=ustawienie w pliku jednostki serwisowej, które określa konto użytkownika.

Gdy system zarządzania demonem odradza proces, który jest demonem, mechanizmy te usuwają uprawnienia administratora, aby proces demon kontynuował działanie pod egidą nieuprzywilejowanego konta użytkownika.

Istnieje dość długie wytłumaczenie, dlaczego dobre zarządzanie demonem odbywa się w ten sposób. Ale nie pytałeś dlaczego; tylko kiedy, jak i skąd. ☺ Bardzo krótka zasada, dlatego:

Systemy operacyjne Unix i Linux izolują procesy działające pod egidą różnych kont użytkowników. Historycznie, jeśli ktoś był w stanie przejąć demona, który działał jako superużytkownik, mógł zrobić wszystko, co mu się podobało. Z drugiej strony demon działający pod egidą nieuprzywilejowanego konta może uzyskiwać dostęp tylko do plików, katalogów, urządzeń i procesów, do których może mieć to konto nieuprzywilejowane. System wzajemnie niezaufanych programów dæmon działających pod egidą różnych kont użytkowników i niezdolnych do uzyskania dostępu / kontroli (wewnętrznych, zaufanych) plików / katalogów / procesów / urządzeń jest znacznie trudniejszy do złamania.

Dalsza lektura

• Jonathan de Boyne Pollard (2014). Rzut oka na skrypty uruchamiania i jednostki usługowe. . Często udzielane odpowiedzi.
• Obsługa kont w skryptach administratora . Debian Wiki.
• Pakowanie: UsersAndGroups . Wiki projektu Fedora.
• „Rozdział 15. Użytkownicy i grupy” . Linux Standardowa specyfikacja podstawowa 2.1 . 2004. Free Standards Group.
• „9.2 Użytkownicy i grupy” . Podręcznik polityki Debiana . 22.11.2014. Lista dyskusyjna zasad Debiana.
• „37.3. Użytkownicy standardowi” . Przewodnik wdrażania RHEL . 11. edycja. 2013. Red Hat.
• Użytkownicy i grupy . Arch wiki.
• Carol Hurwitz i Scott McPeak (2001-02-12). Zlikwiduj główne demony! . DOI 10.1.1.120.3567 .

W systemie Linux, gdy instalujemy usługę, tworzy ona nazwę swojej usługi lub podobną do niej, aby nie mogła uzyskać dostępu do innych plików.