Dlaczego mogę tworzyć użytkowników z tym samym UID?

Moje rozumienie UID jest takie, że jest to unikalna dodatnia liczba całkowita przypisywana przez system operacyjny podobny do Uniksa każdemu użytkownikowi. Każdy użytkownik jest identyfikowany w systemie za pomocą identyfikatora UID, a nazwy użytkowników są zwykle używane tylko jako interfejs dla ludzi.

W jaki sposób dwóch użytkowników może mieć ten sam identyfikator UID, czy nie jest to konflikt dla mojego systemu i pakietów?

root@kdc:~# id test12
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~# id test13
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~#

Dodałem dwóch użytkowników o tym samym UID i GID: test12i test13

Dane wyjściowe /etc/passwd:

client@kdc:~$ cat /etc/passwd | grep test12
test12:x:1005:1000::/home/test12:/bin/sh
client@kdc:~$ cat /etc/passwd | grep test13
test13:x:1005:1000::/home/test13:/bin/sh

Dodałem użytkowników przez useradd -ou 1005 -g1000 username.

Zdezorientowałem się, jaki jest tego cel i czy może to wpłynąć na uprawnienia i dzienniki użytkowników itp. Więc teraz, jeśli użytkownik zostanie dodany uid=0i gid=0będzie miał uprawnienia jak konto root?

Odpowiedź brzmi: Linux nie chroni cię przed sobą.

Jeśli naprawdę chcesz su rootprzejść do plików / etc i dać wszystkim użytkownikom ten sam UID, możesz. To tylko plik tekstowy.

Ale tak naprawdę nie powinieneś i będzie to miało niezamierzone konsekwencje.

Istnieją właściwie uzasadnione powody. Na przykład pracowałem w laboratorium, w którym każdy z nas miał własny komputer, ale $HOMEznajdowaliśmy się na dysku udostępnionym eksportowanym przez serwer. Tak $HOMEbyło

/users/terdon

Ponieważ /usersfolder nie był w rzeczywistości na moim komputerze lokalnym, ale został wyeksportowany przez NFS, do każdej analizy, która była bardzo obciążona na I / O, użyłbym danych przechowywanych na lokalnych dyskach twardych, aby nie obciążać sieci laboratorium. W tym celu ja i wszyscy inni mieliśmy dwóch użytkowników: jednego ogólnosystemowego i jednego lokalnego dla danej maszyny. Dom użytkownika lokalnego był

/home/localuser

Jednak musiałem mieć pełny dostęp do moich plików, czy byłem zalogowany jako terdonlub jak localuseri sposób, w jaki nasz administrator wprowadziły że był dając zarówno localuseri terdontakie same UID. W ten sposób mogłem swobodnie manipulować plikami lokalnymi, niezależnie od tego, jakiego użytkownika jestem aktualnie zalogowany.

Dwóch użytkowników może mieć ten sam identyfikator UID, ponieważ jest to tylko liczba w pliku tekstowym, dzięki czemu można ustawić dowolną wartość, w tym wartość, która jest już używana. Jak widzieliście, robienie tego nie jest dobrym pomysłem.

W rzeczywistości dość powszechne jest posiadanie dwóch użytkowników o tym samym identyfikatorze. We FreeBSD zwykle jest dwóch użytkowników z UID 0: root i toor. Root korzysta z wbudowanej powłoki / bin / sh, a toor używa innej powłoki, zwykle bash.

Systemy Unix i Linux zasadniczo nie robią nic, aby zabronić duplikatów w /etc/passwdpliku. Celem tego pliku jest powiązanie identyfikatora UID z nazwą fizyczną, która może być wyświetlana za pomocą narzędzi wiersza poleceń, na przykład lsgdy użytkownik wymienia pliki.

$ ls -n | head -5
total 986000
drwxrwxr-x.   3 1000 1000      4096 Feb 13 19:51 1_archive_sansa
-rw-rw-r--.   1 1000 1000    760868 Dec 16 08:21 2.18.x Database Scheme.jpg
-rw-rw-r--.   1 1000 1000       972 Oct  6 20:26 abcdefg
drwxrwxr-x.   2 1000 1000      4096 Feb 11 03:34 advanced_linux_programming

Innym zamierzonym celem tego pliku jest określenie, jaką powłokę otrzyma użytkownik po zalogowaniu.

$ getent passwd saml
saml:x:1000:1000:saml:/home/saml:/bin/bash

Typowym wektorem ataku na systemy typu Unix jest dodawanie takich wierszy do /etc/passwdpliku systemowego :

$ getent passwd r00t
r00t:x:0:0:root:/root:/bin/bash

$ getent passwd toor
toor:x:0:0:root:/root:/bin/bash

Rola /etc/passwdpliku NIE ma na celu wyłącznie śledzenia kont użytkowników. Rolą śledzenia nazwy użytkownika i hasła jest /etc/shadowplik. Pliki takie jak /etc/passwdi /etc/groupmają naprawdę nadać czytelną dla człowieka nazwę, gdy system wyświetla pliki z dysków.

Pamiętaj, że twoje pliki są zapisywane na dysk przy użyciu nie rzeczywistych nazw UID / GID.

$ stat afile 
  File: ‘afile’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fd02h/64770d    Inode: 6560621     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/    saml)   Gid: ( 1000/    saml)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2014-02-27 15:54:21.852697029 -0500
Modify: 2014-02-27 15:54:21.852697029 -0500
Change: 2014-02-27 15:54:21.852697029 -0500
 Birth: -

Zwróć uwagę na Uid:i Gid:, liczby są faktycznie zapisane na dysku!

W systemie Linux wszyscy użytkownicy i grupy są w rzeczywistości tylko liczbami. Tak idpokazuje wynik opublikowanego polecenia.

/etc/passwdPlik mapy użytkownika nazwy do użytkownika identyfikatory (numery) i na przykład trzeba zapewnić, ty po prostu dwie nazwy użytkownika odwzorowywane do tego samego identyfikatora użytkownika.

W efekcie utworzyłeś jednego użytkownika, test12ID 1005, który ma także drugą nazwę użytkownika test13. Jednak system odwzoruje UID 1005 na pierwszą znalezioną nazwę użytkownika, która byłabytest12

Linux „pozwala” to zrobić, ponieważ nie ma systemu, który by to uniemożliwił. /etc/passwdjest tylko plikiem tekstowym, nazwy użytkowników są mapowane na identyfikator UID znaleziony dla ich wpisu w tym pliku, identyfikatory UID są mapowane na pierwszą nazwę użytkownika znalezioną w tym pliku.

Ale to, co stworzyłeś, jest mylącą sytuacją dla innych administratorów systamów; unikaj go, zmieniając identyfikator UIDtest13

Powodem tego jest dziś to, że system tego nie zapobiega.

Gdyby to się zmieniło, spowodowałoby to awarię systemów, w których administratorzy używali tej funkcji (patrz przykład Terdona). Więc to nigdy nie zostało zmienione i nie sądzę, że to się kiedykolwiek zmieni.

Pierwotnie były tylko pliki passwd i pliki grupowe i spełniały swoje zadanie. nie było komendy adduser , żadnej addgroup , pliki były edytowane przez root przy pomocy vi lub ed.

Było kilka dziwactw!

W celu zapamiętania następnego identyfikatora użytkownika, administratorzy często mieli specjalnego użytkownika jako ostatni wiersz, który miał nazwę użytkownika !(ponieważ !była to niepoprawna nazwa użytkownika) i ten wpis był używany do przechowywania następnego identyfikator użytkownika. Przyznaję, surowy, ale zadziałało! Po co więc rozwalać jelito, co czyni je bardziej skomplikowanym, podobnie jak dzisiaj zwinny rozwój.

Były znane wady. Najważniejsze jest to, że musi on być czytelny na całym świecie, aby narzędzia takie lsmogły mapować user-id => name. Oznaczało to, że każdy mógł zobaczyć zaszyfrowane hasło wszystkich użytkowników oraz wszystkich użytkowników i identyfikatorów w systemie.

Niektóre systemy uniksowe zaczęły wprowadzać kilka skryptów powłoki adduser addgroup, często były one ignorowane, ponieważ były niespójne między Uniksami, więc większość ludzi kontynuowała ręczną edycję.

Zanim shadowwymyślono plik haseł , minęło kilka lat, co zapewniło nieco większe bezpieczeństwo, ukrywając zaszyfrowane hasła. Ponownie dodano wystarczającą złożoność, ale wciąż była dość prymitywna i prosta. Narzędzia useraddi groupaddzostały wprowadzone, które były utrzymywane shadowi shadow-aktualizowane. Na początek były to często proste opakowania skryptów powłoki wokół zastrzeżonych narzędzi adduser / addgroup dostawców . Znów wystarczyło, by iść dalej.

Sieci komputerów rosły, ludzie pracowali nad kilkoma na raz, aby wykonać zadania, więc administrator passwd/groupplików stał się koszmarem, szczególnie z NFS, więc przychodzi Yellow Pages znany również jako NIS, aby zmniejszyć obciążenie.

Stało się już oczywiste, że potrzeba czegoś bardziej elastycznego i wynaleziono PAM. Więc jeśli byłeś naprawdę wyrafinowany i chciałeś scentralizowanego, bezpiecznego, unikalnego systemu uwierzytelniania z wszystkimi dzwonkami i gwizdkami, wezwałbyś do centralnego serwera w celu uwierzytelnienia, może to być serwer Radius, serwer LDAP lub Active Directory.

Świat urósł. Ale pliki passwd / group / shadow wciąż pozostały dla nas mniejszych użytkowników / programistów / laboratoriów. Wciąż nie wymagaliśmy wszystkich dzwonków i gwizdków. Wydaje mi się, że filozofia zmieniła się już trochę: „Jeśli chcesz to poprawić, wcale byś jej nie użył” , więc nie martw się.

Dlatego nie sądzę, aby prosty plik passwd kiedykolwiek się zmienił. Nie ma już sensu i jest po prostu świetny dla tych Raspberry Pi za 30 £ z 2, może 3 temperaturami monitorowania użytkownika i twitterowymi kanałami. OK, musisz być ostrożny z identyfikatorami użytkowników, jeśli chcesz, aby były unikalne, i nic nie stoi na przeszkodzie, aby entuzjasta zawinął userdd w skrypcie, który najpierw wybiera następny unikalny identyfikator z bazy danych (pliku), aby ustawić unikalny identyfikator, jeśli tego właśnie chcesz. W końcu jest to oprogramowanie typu open source.

/etc/passwdPlik mapy tylko symboliczne nazwy użytkowników do realnej identyfikator użytkownika. Jeśli celowo utworzysz dwie symboliczne nazwy, które będą mapowane na jeden identyfikator użytkownika, pozwoli ci to.

To nie znaczy, że warto to zrobić. Niektóre osoby mogły znaleźć bardzo konkretne przypadki użycia, w których mogą skorzystać z tej funkcji, ale ogólnie nie powinieneś tego robić.

Linux (i inne systemy UNIX) uważają, że administrator wie, co robią. Jeśli powiesz mu, żeby zrobiło coś głupiego, to twoja wina, podobnie jak jeśli powiesz swojemu samochodowi, żeby przejechał klif, nie możesz udać się do producentów i zapytać, dlaczego samochód ci na to pozwolił.

Istnieją identyfikatory, których system operacyjny spodziewa się, że będą unikalne, ale służą one do śledzenia sprzętu. Świadomość, że konkretny unikatowy identyfikator uniwersalny odpowiada dyskowi twardemu zawierającemu pliki systemowe, może pomóc mu kontynuować pracę w przypadku zmiany konfiguracji sprzętu. Microsoft nazywa te globalnie unikalne identyfikatory i używa ich do śledzenia całego oprogramowania Windows. Jak na ironię, te akronimy zostały źle wybrane.

Z punktu widzenia systemu operacyjnego większość zmian identyfikatorów użytkowników i grup sprowadza się do zmiany interfejsu zewnętrznego. Może działać normalnie pomimo kolizji; przede wszystkim od użytkowników i grup systemu wymaga się, aby istnieli. Nie może wiedzieć, czego wymagają użytkownicy. W takich sytuacjach filozofia uniksowa mówi, że system operacyjny powinien zakładać, że administratorzy wiedzą, co robią, i powinien im pomóc to zrobić szybko.

Znalazłem dowody potwierdzające odpowiedź @ andybalholm.

Od APUE , pkt 8.15:

Każdy proces może znaleźć swój rzeczywisty i efektywny identyfikator użytkownika i identyfikator grupy. Czasami jednak chcemy znaleźć nazwę użytkownika, który uruchamia program. Możemy wywołać getpwuid( getuid()), ale co jeśli pojedynczy użytkownik ma wiele nazw logowania, każdy z tym samym identyfikatorem użytkownika? ( Osoba może mieć wiele wpisów w pliku haseł o tym samym identyfikatorze użytkownika, aby mieć inną powłokę logowania dla każdego wpisu .) System zwykle śledzi nazwę, pod którą się logujemy (sekcja 6.8), a getloginfunkcja zapewnia sposób aby pobrać tę nazwę logowania.

....

Biorąc pod uwagę nazwę logowania, możemy jej użyć do wyszukania użytkownika w pliku hasła - na przykład w celu określenia powłoki logowania - za pomocą getpwnam.

Przy okazji chciałbym wiedzieć, czy można się przełączyć na inną powłokę podczas logowania.