Jak mogę wyświetlić listę wszystkich utworzonych przeze mnie użytkowników? Próbowałem cat /etc/passwd
i po prostu wymienia wiele rzeczy.
źródło
Jak mogę wyświetlić listę wszystkich utworzonych przeze mnie użytkowników? Próbowałem cat /etc/passwd
i po prostu wymienia wiele rzeczy.
Użytkownicy mają identyfikatory UID zaczynające się od 1000, więc możesz użyć tego faktu, aby odfiltrować osoby niebędące ludźmi:
cut -d: -f1,3 /etc/passwd | egrep ':[0-9]{4}$' | cut -d: -f1
To odcina pierwsze (nazwa użytkownika) i trzecie (UID) pola rozdzielane dwukropkiem /etc/passwd
, następnie filtruje wynikowe linie, które kończą się dwukropkiem i czterema cyframi, a następnie wycina z tego pierwsze pole (nazwa użytkownika), pozostawiając ci listę użytkownicy z identyfikatorami UID między 1000 a 9999.
Jeśli masz w systemie ponad dziewięć tysięcy użytkowników, to się nie powiedzie - ale konieczne jest ograniczenie wyniku do 4-cyfrowych nobody
identyfikatorów UID, aby nie zostać złapanym (UID 65534).
Robi to prawie tak samo, jak akceptowana odpowiedź , tylko w jednym poleceniu zamiast trzech:
awk -F: '$3 >= 1000 && $1 != "nobody" {print $1}' /etc/passwd
Dzięki Karelowi w komentarzach nobody
użytkownik jest również odfiltrowywany.
Osobiście lubię używać tylko:
Trzeba przyznać, że nie jest to lista użytkowników, ale lista ich katalogów domowych. Obecnie istniejący użytkownicy systemu w systemie będą mieli katalogi domowe
/home
, ale możesz także zobaczyć katalogi domowe użytkowników, którzy zostali usunięci.Działa to dla moich celów i może również działać dla twojego. Na przykład, jeśli chcesz usunąć konto użytkownika, które, jak się okazuje, już nie istnieje (
nonexistent-user
) i uruchom poleceniepowie Ci tylko, że ten użytkownik nie istnieje.
źródło
/home
(do którego nie jest dowiązanie symboliczne/home
), niż że ludzki użytkownik będzie miał UID poniżej 1000 (w końcu jest to najczęstsza metoda powstrzymywania menedżera wyświetlania od wyświetlania użytkownik na ekranie logowania, co czasami może być zrobione dla użytkownika). Jedyną stosunkowo niewielką wadą jest to, żelost+found
zostaną wymienione w systemach z oddzielnymi/home
partycjami.useradd --no-create-home username
?useradd --no-create-home
- katalog domowy może już istnieć lub może zostać utworzony wkrótce potem - alels /home
metoda działa dobrze w tych przypadkach.Chociaż może się to wydawać jednoznacznym pomysłem, w rzeczywistości w znaczeniu ludzkiego użytkownika występuje dwuznaczność . Czy konto użytkownika celowo jest ukryte przed ekranem logowania, ponieważ jest używane wyłącznie do celów specjalistycznych (ale przez ludzi) jako użytkownik? Co z
ubuntu
użytkownikiem (UID 999) na Live CD? Konta gości w Ubuntu są tworzone w locie i niszczone po wylogowaniu; czy są to ludzie? Można wymyślić więcej przykładów.Dlatego dobrze jest, jeśli podano wiele nie równoważnych odpowiedzi. Rozwiązanie Saige Hamblin w biegu
ls /home
jest to, co ludzie faktycznie zrobić i chyba piszesz skrypt, należy prawdopodobnie tylko użyć.Zwiększanie
ls /home
niezawodnościAle może masz użytkowników, którzy zostali usunięci, ale których katalogi domowe nadal istnieją
/home
i musisz ich unikać. A może z jakiegoś innego powodu musisz się upewnić,/home
że wymienione są tylko wpisy na koncie rzeczywistym.W tym przypadku proponuję przechodząc nazwiska wszystko w
/home
celugetent
(aby odzyskaćpasswd
dane użytkowników z tymi nazwami), następnie wyizolować i wyświetlać jedynie polu nazwy użytkownika (zgrep
,sed
lubawk
, zgodnie z preferencjami). Każdy z nich zrobi:Powinno to działać dobrze, ponieważ nie powinieneś mieć kont użytkowników ze spacjami lub znakami kontrolnymi w ich nazwach; nie może tego zrobić bez ponownej konfiguracji Ubuntu, aby na to pozwolić ; a jeśli tak, masz większe problemy. W związku z tym zwykłe problemy z parsowaniem
ls
nie mają zastosowania. Ale nawet jeśli jest to naprawdę w porządku, jeśli weźmiesz pod uwagę zastępowanie poleceńls
nieprzyjemnym estetycznie lub po prostu złym nawykiem, możesz preferować:Nie uwzględniają też białych znaków ani znaków kontrolnych. Zapewniam je tylko dlatego,
$(ls /home)
że wygląda źle, nawet gdy jest to właściwe, a zatem pociera wielu użytkowników w niewłaściwy sposób. W większości sytuacji istnieją rzeczywiste, dobre powody, aby unikać analizowanials
, a w takich sytuacjach przetwarzaniebasename -a
jest zwykle tylko nieznacznie mniej złe. Jednak w tej sytuacji, ze względu na ograniczenie tego, jakie znaki mogą praktycznie występować w nazwach użytkowników , oba są w porządku.Wyjaśnienie, zalety i wady
Używam
getent
głównie dlatego, że akceptuje nazwy użytkowników jako argumenty w celu ograniczenia wyników, ale także dlatego, że jest nieco bardziej uniwersalny niż/etc/passwd
bezpośrednie sprawdzanie , w przypadku gdy usługi uwierzytelniania zapewniają bazę danych haseł i usługi.Ta metoda ma tę dodatkową zaletę,
ls /home
że w systemach z oddzielną/home
partycjąlost+found
zwykle pojawia się na wyjściuls /home
.lost+found
pojawi się tylko wtedy, gdy zdarzy się, że zadzwoni użytkownik (człowiek lub nie)lost+found
, co jest mało prawdopodobne.ls /home
jest fine-- ty wiesz, że nie ma człowieka użytkownika o nazwielost+found
.Nierzadko ta metoda (w dowolnej z powyższych odmian) generuje niezadowalającą wydajność:
/home
lub wcale, sugeruje to, ale nie oznacza, że konto nie powinno być traktowane jako reprezentujące użytkownika. Ta metoda wyświetla listę użytkowników tylko wtedy, gdy istnieje katalog o tej samej nazwie/home
./home
które w rzeczywistości nie są niczyim katalogiem domowym, a tak się składa , że mają taką samą nazwę jak istniejący użytkownik inny niż człowiek - lub składają się ze słów oddzielonych białymi spacjami, z których co najmniej jeden ma taką samą nazwę jako istniejący użytkownik inny niż człowiek, wówczas niektórzy użytkownicy niebędący ludźmi mogą zostać włączeni do wyniku.(Metodę tę można zaimplementować za pomocą pętli i osobnych
getent
wywołań, dzięki czemu dzielenie słów nie daje fałszywych wyników. Ale złożoność nie jest uzasadniona; zasadniczo, jeśli używasz/home
czegoś innego niż miejsce na katalogi domowe użytkowników, ta metoda będzie nie produkują wiarygodnych wyników).Uproszczenie sprawdzania UID
Jeśli zdecydujesz się na metodę, która sprawdza identyfikatory użytkowników, aby upewnić się, że znajdują się one w prawdopodobnym zakresie dla kont reprezentujących ludzi, tak jak w zaakceptowanej odpowiedzi lub odpowiedzi Oli , sugeruję to dla zwięzłości:
Używa wyrażenia regularnego Perl (
-P
), aby pokazać:^
) nie zawierającego:
s ([^:]+
) - jest to pierwsze pole, podobnie jak:
separator pól wpasswd
(?=
)
) pola hasłax
- zawsze powinno byćx
, ponieważ w Ubuntu skróty haseł są przechowywane wshadow
bazie danych, a nie wpasswd
bazie danych odczytywalnej na całym świecie:\d{4}:
).Jest to zatem znacznie krótszy i nieco prostszy wariant techniki w przyjętej odpowiedzi . (Opisana tam technika również działa dobrze i ma tę zaletę, że jest przenośna dla systemów innych niż GNU / Linux, których
grep
nie obsługuje-P
.)Ponowne rozpatrzenie zakresu UID „Ludzkiego”
Jeśli chcesz uwzględnić bardzo wysokie identyfikatory UID i
nobody
wyraźnie je sprawdzić , możesz użyć metody z odpowiedzi Oli . Możesz jednak rozważyć, czy użytkownicy o bardzo wysokich identyfikatorach UID naprawdę powinni zostać uznani za ludzi, czy też bardziej prawdopodobne jest, że będą to użytkownicy o innym przeznaczeniu niż ludzie (jaknobody
). W praktyce tacy użytkownicy - poza tym -nobody
są rzadcy, więc tak naprawdę jest to decyzja z twojej strony.Możliwym kompromisem jest wyświetlenie listy użytkowników w zakresie identyfikatorów UID , którzy faktycznie są przypisywani do nowo utworzonych użytkowników niesystemowych. Możesz to sprawdzić w
adduser.conf
:Oto dwa sposoby wyświetlania listy użytkowników, których UID mają zakres od 1000 do 29999:
źródło
basename
jest brzydka. To nie jest lepsze niżls
. Głównym powodem, dla którego nie analizujemy, jest to, że jest to praca, którą inne narzędzia mogą wykonać znacznie bezpieczniej i czysto, a nie stylowo. W tym przypadku, powłoka:cd /home; getent passwd *
.ls
dotyczy zazwyczaj stylu. Drugi punkt dotyczący „niezadowalającej wydajności” dotyczył tego problemu, ale pojawia się w dalszej części. Przeredagowałem, aby wyjaśnić, dlaczego analizals
jest odpowiednia w tej sytuacji . Chociażcd /home; getent passwd *
przybiera formę często wskazującą na podejście sygnalizatora, unikałem go, aby nie doprowadzić czytelników do przekonania, że zawartość/home
katalogów, z dziwnymi dodanymi wpisami nie odpowiadającymi prawdziwym użytkownikom, nadal może być w jakiś sposób wykorzystywana jako przewodnik po tym, co użytkownicy istnieją.TL; DR : tylko użytkownicy mają SystemAccount = false
Innym sposobem jest wyświetlenie listy wyników, ignorując root
ls /var/lib/AccountsService/users/ | grep -v root
. Teraz jest dziwactwo - gdm, ekran powitania / logowania (lub bardziej formalnie menedżer pulpitu) jest również wymieniony jako użytkownik. Więc po prostu z listy nie możemy stwierdzić, czy gdm jest człowiekiem, czy nie.Bardziej wydajnym i poprawnym podejściem jest przejrzenie plików w tym folderze i sprawdzenie, którzy użytkownicy są na liście jako posiadający
SystemAccount=false
. Osłona jednowarstwowa osiąga togrep SystemAccount=false /var/lib/AccountsService/users/* | awk -F '/' '{gsub(":","/");print $6}'
źródło
mini.iso
bez menedżerów wyświetlania lub X11) mam jedno konto użytkownika -/var/lib/AccountsService/users
jest to jednak pusty katalog. Oczekuję, że to również nie zadziała w przypadku instalacji gotowego serwera Ubuntu. Ponadto, gdy to działa, robi to pod nieco ograniczonym pojęciem, co powoduje, że konto użytkownika jest „ludzkie”: utworzenie użytkownikauseradd
, nawet bez niego--system
, nie tworzy plikuAccountsService/users
.Dołączając do partii, nadzoruję systemy sieciowe korzystające z LDAP, mające
/home
miliony katalogów domowych i UID (z powodu usterki skryptowej). Dlatego żadna z obecnych odpowiedzi nie działa. Test, który działa dla mnie, polega na sprawdzeniu, czy użytkownik ma prawidłową powłokę logowania. Prawidłowa powłoka jest wymieniona w/etc/shells
. Najprostsza forma:Plik może zawierać komentarze (lub puste linie), więc może być konieczne ich odfiltrowanie:
źródło
root
(co prawdopodobnie nie powinno być uważane za użytkownika), ponieważ ludzie zwykle rootują tymczasowo i do określonych celów, zamiast używać go do swojej zwykłej pracy), wydaje się, że najmniej prawdopodobne jest, że zawiedzie jakikolwiek większy sposób. Metody w innych odpowiedzi (w tym moje) może nie, w zależności od sposobu, jeśli katalogi domowe nie są/home
, inne śmieci jest w/home
, UID są dziwne, czy system nie korzysta z DM. Ta odpowiedź działa całkiem dobrze we wszystkich tych scenariuszach.W systemach buntu zwykli użytkownicy (tj. Użytkownicy) mają identyfikatory UID zaczynające się od 1000, które są im przypisywane sekwencyjnie przy pierwszym tworzeniu ich kont. Wszystko sprowadza się do tego, że pierwsze konto utworzone w systemie buntu ma identyfikator UID wynoszący 1000. Kolejne utworzone konto ma identyfikator UID 1001. I tak dalej.
Tak więc, moim zdaniem, najprostszym sposobem wylistowania wszystkich kont użytkowników obecnych w systemie jest sprawdzenie, czy trzecia kolumna w
/etc/passwd
pliku zawierającym UID użytkownika jest większa lub równa 1000 i mniejsza niż, powiedzmy, 2000 (jest mało prawdopodobne, aby typowy komputer stacjonarny miał więcej niż tysiąc kont użytkowników, nie sądzisz?):źródło
nobody
. =)