Wiele * kont NIX z identycznym identyfikatorem UID

Jestem ciekawy, czy istnieje standardowe oczekiwane zachowanie i czy jest to uważane za złą praktykę przy tworzeniu więcej niż jednego konta w systemie Linux / Unix, które mają ten sam UID. Zrobiłem z tym kilka testów RHEL5 i zachowałem się tak, jak się spodziewałem, ale nie wiem, czy kusi los za pomocą tej sztuczki.

Jako przykład załóżmy, że mam dwa konta o tych samych identyfikatorach:

a1:$1$4zIl1:5000:5000::/home/a1:/bin/bash
a2:$1$bmh92:5000:5000::/home/a2:/bin/bash

Oznacza to:

• Mogę zalogować się na każde konto przy użyciu własnego hasła.
• Pliki, które utworzę, będą miały ten sam identyfikator UID.
• Narzędzia takie jak „ls -l” będą wyświetlać UID jako pierwszy wpis w pliku (w tym przypadku a1).
• Unikam problemów z uprawnieniami lub własnością między tymi dwoma kontami, ponieważ są one naprawdę tym samym użytkownikiem.
• Dostaję kontrolę logowania dla każdego konta, więc mam większą szczegółowość w śledzeniu tego, co dzieje się w systemie.

Więc moje pytania to:

• Czy ta umiejętność jest zaprojektowana, czy tak właśnie działa?
• Czy będzie to spójne dla wszystkich wariantów * nix?
• Czy to przyjęta praktyka?
• Czy są to niezamierzone konsekwencje dla tej praktyki?

Uwaga: tutaj chodzi o użycie tego w przypadku kont systemowych, a nie zwykłych kont użytkowników.

Moja opinia:

Czy ta umiejętność jest zaprojektowana, czy tak właśnie działa?

Jest zaprojektowany. Odkąd zacząłem używać * NIX, możesz umieszczać użytkowników we wspólnych grupach. Możliwość ustawienia identyfikatora UID bez problemów jest tylko zamierzonym rezultatem, który, podobnie jak wszystko, może powodować problemy, jeśli jest nieprawidłowo zarządzany.

Czy będzie to spójne dla wszystkich wariantów * nix?

Tak mi się wydaje.

Czy to przyjęta praktyka?

Zaakceptowane jako ogólnie używane w taki czy inny sposób, tak.

Czy są to niezamierzone konsekwencje dla tej praktyki?

Poza kontrolą logowania nie masz nic więcej. Chyba że dokładnie tego chciałeś, na początek.

Czy będzie działać na wszystkich systemach uniksowych? Tak.

Czy to dobra technika w użyciu? Nie. Są inne techniki, które są lepsze. Na przykład właściwe użycie grup uniksowych i ściśle kontrolowane konfiguracje „sudo” mogą osiągnąć te same rzeczy.

Widziałem dokładnie jedno miejsce, w którym był używany bez problemów. We FreeBSD tradycyjnie tworzy się drugie konto root o nazwie „toor” (root pisane wstecz), które ma domyślną powłokę / bin / sh. W ten sposób, jeśli powłoka roota zostanie pomieszana, nadal możesz się zalogować.

Nie mogę udzielić kanonicznej odpowiedzi na twoje pytania, ale anegdotycznie moja firma robi to od lat z użytkownikiem root i nigdy nie miała z tym żadnych problemów. Tworzymy użytkownika „kroot” (UID 0), którego jedynym powodem istnienia jest posiadanie / bin / ksh jako powłoki zamiast / bin / sh lub bin / bash. Wiem, że nasze Oracle DBA robią coś podobnego ze swoimi użytkownikami, mając 3 lub 4 nazwy użytkownika na instalację, wszystkie z tymi samymi identyfikatorami użytkowników (uważam, że zrobiono to, aby mieć osobne katalogi domowe dla każdego użytkownika. Robiliśmy to przynajmniej dziesięć lat w systemach Solaris i Linux. Myślę, że działa zgodnie z planem.

Nie zrobiłbym tego na zwykłym koncie użytkownika. Jak zauważyłeś, po pierwszym logowaniu wszystko wraca do pierwszego imienia w pliku dziennika, więc myślę, że działania jednego użytkownika mogą być maskowane jako działania innego w logach. W przypadku kont systemowych działa jednak świetnie.

Czy ta umiejętność jest zaprojektowana, czy tak właśnie działa?

Zaprojektowany w ten sposób.

Czy będzie to spójne dla wszystkich wariantów * nix?

Powinno tak.

Czy to przyjęta praktyka?

Zależy, co masz na myśli. Ten rodzaj rzeczy rozwiązuje niezwykle specyficzny problem (patrz konta root / toor). Gdziekolwiek indziej, a ty prosisz o głupi problem w przyszłości. Jeśli nie masz pewności, czy jest to właściwe rozwiązanie, prawdopodobnie nie jest.

Czy są to niezamierzone konsekwencje dla tej praktyki?

Jest ogólnie przyjęte, że nazwy użytkowników i UID są traktowane jako wymienne. Jak zauważyło kilka innych osób, kontrole logowania / aktywności będą niedokładne. Będziesz także chciał przejrzeć zachowanie wszelkich odpowiednich skryptów / programów związanych z użytkownikiem (useradd, usermod, skrypty userdel, wszelkie skrypty okresowej konserwacji itp.).

Co próbujesz osiągnąć przy pomocy tego, czego nie można osiągnąć, dodając tych dwóch użytkowników do nowej grupy i przyznając tej grupie potrzebne uprawnienia?

Czy są to niezamierzone konsekwencje dla tej praktyki?

Jest jeden problem, o którym wiem. Cron nie gra dobrze z tym aliasingiem UID. Spróbuj uruchomić „crontab -i” ze skryptu Python, aby zaktualizować wpisy cron. Następnie uruchom „crontab -e” w powłoce, aby zmodyfikować to samo.

Zauważ, że teraz cron (vixie, myślę) zaktualizuje te same wpisy dla obu a1 i a2 (w / var / spool / cron / a1 i / var / spool / cron / a2).

Jest to oczekiwane zachowanie we wszystkich dystrybucjach, które widziałem, i jest to powszechna sztuczka, której „wróg” używa do ukrywania kont z dostępem do konta root.

Z pewnością nie jest to standard (nigdzie nie widziałem tego w grze), ale nie powinno być żadnego powodu, dla którego nie można tego używać we własnym środowisku, jeśli uważasz to za stosowne.

Jedyne, co teraz przychodzi mi na myśl, to fakt, że może to utrudnić kontrolę. Jeśli masz dwóch użytkowników z tym samym identyfikatorem UID / GID, uważam, że trudno ci będzie ustalić, który z nich zrobił to, co analizowałeś logi.

Udostępnianie identyfikatorów grup podstawowych jest częste, więc pytanie dotyczy naprawdę UID .

Zrobiłem to już wcześniej, aby dać komuś dostęp do roota, bez ujawniania hasła roota - co zadziałało dobrze. (chociaż myślę, że sudo byłoby lepszym wyborem)

Najważniejszą rzeczą, na którą chciałbym zachować ostrożność, jest usunięcie jednego z użytkowników - program może się pomylić i usunąć zarówno użytkowników, jak i pliki należące do obu lub podobne rzeczy.

W rzeczywistości myślę, że programiści prawdopodobnie zakładają związek 1: 1 między użytkownikiem a UID, więc bardzo dobrze mogą wystąpić nieoczekiwane konsekwencje z innymi programami podobnymi do tego, co opisałem dla userdel.

BTW - to pytanie / odpowiedź została zaktualizowana dla dzisiejszych systemów operacyjnych.

Cytując redhat: zarządzanie unikalnymi przypisaniami UID i GID , opisuje użycie UID i GID oraz zarządzanie nimi i sposób, w jaki generatory (serwery ID)

musi generować losowe wartości UID i GID i jednocześnie zapewniać, że repliki nigdy nie będą generować tej samej wartości UID lub GID. Potrzeba unikalnych numerów UID i GID może nawet przekraczać domeny IdM, jeśli jedna organizacja ma wiele różnych domen.

Podobnie narzędzia, które umożliwiają dostęp do systemu, mogą zachowywać się nieprzewidywalnie (to samo odwołanie):

Jeśli dwa wpisy mają przypisany ten sam numer identyfikacyjny, tylko pierwszy wpis jest zwracany podczas wyszukiwania tego numeru.

Problem pojawia się, gdy pojęcie „pierwszy” jest źle zdefiniowane. W zależności od zainstalowanej usługi nazwy użytkowników mogą być przechowywane w haszach o zmiennej wielkości, które zwracałyby inną nazwę użytkownika na podstawie niespójnych czynników. (Wiem, że to prawda, ponieważ czasami próbowałem użyć 2 nazw użytkowników z jednym identyfikatorem, jeden to lokalna nazwa użytkownika, a drugi to nazwa domeny. Nazwa użytkownika, którą chciałem odwzorować na UID (do którego ostatecznie adresowałem w zupełnie inny sposób), ale mógłbym zalogować się za pomocą „usera”, zrobić „who” lub „id” i zobaczyć „userb” LUB „usera” - losowo.

Istnieje interfejs do pobierania wielu wartości UID z grupy (grupy z jednym GID są zaprojektowane do powiązania z wieloma UID), ale nie ma przenośnego interfejsu do zwrócenia listy nazw dla jednego UID, więc każdy spodziewa się tego samego lub podobne zachowanie między systemami, a nawet aplikacjami w tym samym systemie może być nieszczęśliwie zaskoczone.

W Słońcu (teraz wyrocznia) yp (żółte strony) lub NIS (NetworkInformationServices) istnieje również wiele odniesień do wymagań dotyczących wyjątkowości. Specjalne funkcje i serwery są skonfigurowane do przydzielania unikalnych identyfikatorów na wielu serwerach i domenach (na przykład uid_allocd, gid_allocd - strona demonów alokatora UID i GID

Trzecim źródłem, które można sprawdzić, jest dokumentacja serwera Microsoft dotycząca mapowania kont NFS. NFS to uniksowy protokół udostępniania plików, który opisuje, w jaki sposób uprawnienia do plików i dostęp są utrzymywane przez identyfikator. Tam piszą:

• UID. Jest to liczba całkowita bez znaku używana przez systemy operacyjne UNIX do identyfikacji użytkowników i musi być unikalna w pliku passwd.

• KOŁOWACIZNA. Jest to liczba całkowita bez znaku używana przez jądro systemu UNIX do identyfikowania grup i musi być unikalna w pliku grupy. Strona zarządzania MS-NFS

Chociaż niektóre systemy operacyjne mogły zezwalać na wiele nazw / UID (być może pochodne BSD?), Większość systemów operacyjnych zależy od tego, czy są one unikalne i mogą zachowywać się nieprzewidywalnie, gdy nie są.

Uwaga - dodaję tę stronę, ponieważ ktoś odniósł się do tego datowanego wpisu jako obsługi nowoczesnych narzędzi do obsługi nie unikatowych identyfikatorów UID / GID ... których większość nie.

Nie wiem też, czy to dobry pomysł, czy nie, ale powyższego zachowania używam w kilku miejscach. Głównie dotyczy to kont, które służą do uzyskiwania dostępu do serwera ftp / sftp i aktualizowania zawartości strony internetowej. Wydawało się, że nic nie zepsuło i sprawiło, że obsługa uprawnień była łatwiejsza niż w przypadku wielu kont.

Właśnie natrafiłem na (raczej niejasny) problem wynikający z używania wielu kont o tym samym UID i pomyślałem, że podzielę się nim jako przykład tego, dlaczego nie jest to dobra praktyka.

W moim przypadku dostawca skonfigurował serwer bazy danych Informix i serwer aplikacji WWW na RHEL 7. Podczas instalacji utworzono wiele kont „root” z UID 0 (nie pytaj mnie dlaczego). Tj. „Root”, „user1” i „user2”, wszystkie z UID 0.

Serwer RHEL 7 został później przyłączony do domeny Active Directory za pomocą winbind. W tym momencie serwer Informix DB nie mógł już się uruchomić. Uruchomienie oninitkończyło się niepowodzeniem, a komunikat o błędzie informował o tym "Must be a DBSA to run this program".

Oto, co znaleźliśmy podczas rozwiązywania problemów:

1. Uruchomienie id rootlub getent passwd 0(w celu przekształcenia UID 0 w nazwę użytkownika) w systemie dołączonym do Active Directory losowo zwróci albo „użytkownik1” albo „użytkownik2” zamiast „root”.

2. Informix najwyraźniej polegał na porównaniu ciągów, aby sprawdzić, czy tekstowa nazwa użytkownika, który go uruchomił, to „root” i inaczej by się nie udało.

3. Bez winbind id rooti getent passwd 0konsekwentnie zwracałby „root” jako nazwę użytkownika.

Poprawka polegała na wyłączeniu buforowania i trwałości w /etc/nscd.conf:

enable-cache    passwd      no
persistent      passwd      no

Po tej zmianie identyfikator UID 0 ponownie konsekwentnie zmienia się na „root” i Informix może się uruchomić.

Mam nadzieję, że będzie to dla kogoś przydatne.