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

37

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?

nux
źródło
Nie jestem tego pewien, ale myślę, że dane wyjściowe wypisują UID użytkownika „test10” w obu poleceniach. Dlaczego to robię, nie mam pojęcia, ale musi to być użytkownik utworzony wcześniej.
animaletdesequia
jakby jej mówi, że tam jest użytkownik, który ma ten identyfikator
Nux
OK, źle zrozumiałem pytanie. Myślałem, że utworzyłeś użytkowników normalnie, a system przypisał im ten sam UID.
animaletdesequia
nikt nie jest normalnie, pytanie tutaj, w jaki sposób system akceptuje unikalne uids
nux
Rozumiem. Dobre pytanie, dzięki za wyjaśnienie :)
animaletdesequia

Odpowiedzi:

40

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.

Digital Chris
źródło
4
moje pytanie brzmi: dlaczego system to akceptuje?
nux
46
Co masz na myśli mówiąc „zaakceptuj”? Jak by to NIE zaakceptowało? to tak, jakbyś był szefem kuchni i pytał, dlaczego zupa pozwoliła ci wlać za dużo soli. Jeśli chodzi o współczesne komputery, prawdopodobnie przyzwyczaiłeś się do mentalności RDBMS, gdzie ograniczenia dotyczące ważnych rzeczy, takich jak identyfikatory, uniemożliwiają strzelanie sobie w stopę. Identyfikatory użytkowników systemu Linux są znacznie bardziej prymitywne i nie mają wewnętrznego sprawdzania ani poprawiania.
Cyfrowy Chris
5
Zgadza się i za pomocą useradd -orozpoznajesz, że jesteś poza normą adduser. Jak wspomniano @psusi, tworzy dwa loginy wskazujące na ten sam identyfikator w zakresie uprawnień do plików itp. Prawdopodobnie stwarza również problemy, ponieważ nie jest to normalny przypadek użycia i bez wątpienia nie jest testowany z dużą ilością pakietów.
Cyfrowy Chris
2
Odpowiedź: aby 2 loginy wskazywały identyczne uprawnienia systemu plików.
Cyfrowy Chris
5
@Josh, oczywiście, że istnieją ważne powody, aby mieć wielu użytkowników z tym samym UID, zobacz moją odpowiedź na jeden przykład.
terdon
38

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.

terdon
źródło
6
Na poparcie tej odpowiedzi warto zauważyć, że niektóre konfiguracje, takie jak wirtualny hosting poczty e-mail, wykorzystują to z wielkim skutkiem, tj. Ogromna liczba wirtualnych kont e-mail współużytkujących jeden identyfikator UID - dokumentacja serwera poczty Dovecot faktycznie sugeruje to jako opcjonalne podejście na wiki2.dovecot.org/UserIds#mailusers
Matt Thomason
nie chmod 666miałby takich samych efektów?
Brian
3
@GIJoe, który pozwoli obu użytkownikom na odczyt / zapis, ale nie zachowa własności, co może być problemem. Ponadto nie wszystkie pliki można ustawić na te uprawnienia (na przykład klucze ssh) i nie jest praktyczne, aby grać cały czas z uprawnieniami.
terdon
12

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.

psusi
źródło
jak zatem system radzi sobie z użytkownikami? uprawnienia do udostępniania
nux
12
@nux, oboje są tym samym użytkownikiem. Mogą po prostu mieć inną nazwę użytkownika / hasło do celów logowania.
psusi
4
@ bigbadonk420, termin „obsługiwany” jest raczej mglisty. Z pewnością jest to coś, co zawsze byłeś w stanie zrobić w systemach uniksowych. Zwykle było backdoor, aby skonfigurować innego użytkownika, który ma identyfikator użytkownika 0, abyś mógł się zalogować i skutecznie być rootem, bez konieczności znajomości lub zmiany hasła na normalnym użytkowniku root.
psusi
1
@ bigbadonk420 jest obsługiwany, są przypadki, w których jest to przydatne, zobacz moją odpowiedź na jeden przykład.
terdon
11

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.

andybalholm
źródło
11

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!

slm
źródło
9

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

Josh
źródło
to jest mój testowy człowiek wirtualnej maszyny, moje pytanie ma na celu mapowanie dwóch użytkowników dla tego samego identyfikatora użytkownika
nux
1
Jedynym celem, jaki mogę wymyślić, jest nadanie UID drugiej, aliasowanej nazwy użytkownika. Ale jest to niezdefiniowane zachowanie i nie jest zalecane. Naprawdę jest to niepożądana sytuacja: lepiej jest mieć relację 1: 1 między nazwami użytkowników a identyfikatorami UID
Josh
dlatego zadałem to pytanie, które musiałem wiedzieć, czułem, że jest to mylące
nux
To wprowadza zamieszanie; dlatego nie powinieneś tego robić. Nie ma „celu”, jest to raczej niewłaściwe użycie /etc/passwdpliku. Ale nie ma żadnych środków, które mogłyby temu zapobiec . Czy to ma sens?
Josh
1
użytkownik wspomniał, że celem jest, aby 2 loginy wskazywały identyczne uprawnienia systemu plików.
nux
5

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.

X Tian
źródło
2

/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ł.

użytkownik253158
źródło
dlaczego został wymieniony jako błąd?
nux
1

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.

użytkownik130144
źródło
0

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.

Stóg
źródło