Lister tous les utilisateurs humains

Comment répertorier tous les utilisateurs humains que j'ai créés? J'ai essayé cat /etc/passwdet il énumère juste beaucoup de choses.

Les utilisateurs humains ont des UID commençant à 1000, vous pouvez donc utiliser ce fait pour filtrer les non-humains:

cut -d: -f1,3 /etc/passwd | egrep ':[0-9]{4}$' | cut -d: -f1

Cela coupe le premier (nom d'utilisateur) et le troisième (UID) champs délimités par les deux-points de /etc/passwd, puis filtre les lignes résultantes qui se terminent par deux-points et quatre chiffres, puis coupe le premier champ (nom d'utilisateur) de cela, vous laissant avec une liste de utilisateurs avec des UID compris entre 1000 et 9999.

Si vous avez plus de neuf mille utilisateurs sur votre système, cela échouera - mais il est nécessaire de limiter le résultat à des UID à 4 chiffres afin de ne pas intercepter nobody(UID 65534).

Cela fait à peu près ce que fait la réponse acceptée , juste dans une commande au lieu de trois:

awk -F: '$3 >= 1000 && $1 != "nobody" {print $1}' /etc/passwd

Et grâce à Karel dans les commentaires, l' nobodyutilisateur est également filtré.

Personnellement, j'aime utiliser seulement:

ls /home

Certes, ce n'est pas une liste d'utilisateurs mais plutôt une liste de leurs répertoires personnels. Les utilisateurs humains existants sur le système auront des répertoires personnels dans /home, mais vous pouvez également voir les répertoires personnels des anciens utilisateurs qui ont été supprimés.

Cela fonctionne pour mes besoins et peut également fonctionner pour le vôtre. Par exemple, si vous cherchez à supprimer un compte d'utilisateur qui s'avère ne plus exister ( nonexistent-user) et exécutez la commande

sudo deluser nonexistent-user

il vous dira simplement que cet utilisateur n'existe pas.

Bien que cela puisse sembler une idée claire, il y a en fait une ambiguïté dans le sens de l'utilisateur humain . Un compte d'utilisateur est-il délibérément caché de l'écran de connexion car il est utilisé uniquement à des fins spécialisées (mais par des humains) par un utilisateur humain? Qu'en est-il de l' ubuntuutilisateur (UID 999) sur le CD live? Et les comptes invités dans Ubuntu sont créés à la volée et détruits après la déconnexion; sont-ils des utilisateurs humains? D'autres exemples pourraient être imaginés.

Par conséquent, il convient que plusieurs réponses non équivalentes aient été données. La solution de Saige Hamblin pour exécuter ls /homeest ce que les gens font réellement , et à moins que vous n'écriviez un script, vous devriez probablement simplement l'utiliser.

Rendre ls /homeplus robuste

Mais vous avez peut-être des utilisateurs qui ont été supprimés, mais dont les répertoires personnels existent toujours /home, et vous devez éviter de les répertorier. Ou peut-être pour une autre raison, vous devez vous assurer que seules les entrées /homequi correspondent à des comptes réels sont répertoriées.

Dans ce cas, je vous suggère de passer les noms de tout /homeà getent(pour récupérer les passwdentrées des utilisateurs avec ces noms), puis isoler et d' afficher tout le champ nom d' utilisateur (avec grep, sedou awk, selon votre préférence). N'importe lequel d'entre eux fera:

getent passwd $(ls /home) | grep -o '^[^:]*'

getent passwd $(ls /home) | sed 's/:.*//'

getent passwd $(ls /home) | awk -F: '{print $1}'

Cela devrait bien fonctionner, car vous ne devriez pas avoir de comptes utilisateur avec des espaces ou des caractères de contrôle dans leurs noms; ne peut pas, sans reconfigurer Ubuntu pour le permettre ; et si vous le faites, vous avez de plus gros problèmes. Ainsi, les problèmes habituels avec l'analyse lssont inapplicables. Mais même si c'est vraiment bien ici, si vous considérez les substitutions de commandes avec lsun déplaisir esthétique ou simplement une mauvaise habitude, vous pouvez préférer:

getent passwd $(basename -a /home/*) | grep -o '^[^:]*'

getent passwd $(basename -a /home/*) | sed 's/:.*//'

getent passwd $(basename -a /home/*) | awk -F: '{print $1}'

Ceux-ci ne prennent pas non plus en compte les espaces ou les caractères de contrôle. Je ne les fournis que parce que $(ls /home)ça ne va pas, même quand c'est bien, et frotte ainsi de nombreux utilisateurs dans le mauvais sens. Dans la plupart des situations, il existe de vraies bonnes raisons pour éviter l'analysels , et dans ces situations, l'analyse basename -an'est généralement que très légèrement moins mauvaise. Dans cette situation, cependant, en raison de la limitation du nombre de caractères pouvant apparaître dans les noms d'utilisateur , ils conviennent tous les deux.

Explication, avantages et inconvénients

J'utilise getentprincipalement parce qu'il accepte les noms d'utilisateur comme arguments pour restreindre sa sortie, mais aussi parce qu'il est légèrement plus universel que d'examiner /etc/passwddirectement, dans le cas où les fonctionnalités d'authentification et la base de données de mots de passe sont fournies par les services réseau.

Cette méthode présente l'avantage supplémentaire par rapport à ce ls /homeque, sur les systèmes avec une /homepartition séparée , lost+foundapparaît généralement dans la sortie de ls /home.

• Avec la méthode plus robuste présentée ci-dessus, lost+foundn'apparaîtra que s'il se trouve qu'un utilisateur (humain ou non) est appelé lost+found, ce qui est peu probable.
• Mais si vous saisissez des commandes de manière interactive plutôt que d'écrire un script, ls /homec'est bien - vous savez que vous n'avez pas d'utilisateur humain appelé lost+found.

Rarement, cette méthode (dans l'une des variantes ci-dessus) produira une sortie insatisfaisante:

• Si le répertoire personnel d'un utilisateur existe à l'extérieur /home, ou pas du tout, cela suggère mais n'implique pas que le compte ne doit pas être considéré comme représentant un utilisateur humain. Cette méthode répertorie uniquement les utilisateurs lorsqu'il existe un répertoire du même nom dans /home.
• Si vous avez créé des répertoires supplémentaires /homequi ne sont en fait le répertoire personnel de personne et qu'ils ont le même nom qu'un utilisateur non humain existant - ou se composent de mots séparés par des espaces, dont un ou plusieurs portent le même nom en tant qu'utilisateur non humain existant - certains utilisateurs non humains peuvent alors être inclus dans la sortie.
  _{(Cette méthode peut être implémentée avec une boucle et des getentinvocations séparées , donc le fractionnement de mots ne produit pas de sortie parasite. Mais la complexité n'est pas garantie; fondamentalement, si vous utilisez /homeautre chose qu'un endroit pour les répertoires personnels des utilisateurs, cette méthode ne produit pas de sortie fiable.)}

Simplification de la vérification UID

Si vous décidez d'utiliser une méthode qui vérifie les ID utilisateur pour vous assurer qu'ils sont dans la plage probable pour les comptes représentant des êtres humains, comme dans la réponse acceptée ou la réponse d'Oli , alors je suggère ceci pour plus de brièveté:

getent passwd | grep -oP '^[^:]+(?=:x:\d{4}:)'

Cela utilise une expression régulière Perl ( -P) pour montrer:

• texte au début d'une ligne ( ^) ne contenant pas de :s ( [^:]+) - c'est le premier champ, tout comme :le séparateur de champ danspasswd
• qui précède mais n'inclut pas ( (?= )) le champ de mot de passe x- il devrait toujours l'être x, car dans Ubuntu, les hachages de mot de passe sont stockés dans la shadowbase de données, pas dans la base de passwddonnées lisible par le monde
• et un champ UID composé exactement de 4 chiffres ( :\d{4}:).

Il s'agit donc d'une variante beaucoup plus courte et quelque peu plus simple de la technique dans la réponse acceptée . (La technique décrite ici fonctionne également très bien, et elle a l'avantage d'être portable sur des systèmes non GNU / Linux qui grepne prennent pas en charge -P.)

Reconsidérer la gamme UID «humaine»

Si vous souhaitez accepter des UID très élevés et vérifier nobodyexplicitement, vous pouvez utiliser la méthode dans la réponse d'Oli . Cependant, vous voudrez peut-être déterminer si les utilisateurs avec des UID très élevés doivent vraiment être considérés comme humains, ou s'ils sont plus susceptibles d'être un autre utilisateur non humain à des fins spéciales (comme nobody). Dans la pratique, ces utilisateurs - en plus - ne sont nobodypas courants, il s'agit donc vraiment d'un jugement de votre part.

Un compromis possible consiste à répertorier les utilisateurs dans la plage des UID qui sont réellement attribués aux utilisateurs nouvellement créés, non "système". Vous pouvez vérifier cela dansadduser.conf :

$ grep -E '^(FIRST|LAST)_UID' /etc/adduser.conf
FIRST_UID=1000
LAST_UID=29999

Voici deux façons de répertorier les utilisateurs dont les UID vont de 1000 à 29999:

getent passwd | grep -oP '^[^:]+(?=:x:[12]?\d{4}:)'

getent passwd | awk -F: '999<$3 && $3<30000 {print $1}'

TL; DR : seuls les utilisateurs humains ont SystemAccount = false

Une autre façon consiste à répertorier la sortie de tout en ignorant root ls /var/lib/AccountsService/users/ | grep -v root. Maintenant, il y a une bizarrerie - gdm, un écran d'accueil / de connexion (ou plus officiellement un gestionnaire de bureau) est également répertorié en tant qu'utilisateur. Donc, juste en énumérant, nous ne pouvons pas dire si gdm est humain ou non.

Une approche plus efficace et correcte consiste à parcourir les fichiers de ce dossier et à identifier les utilisateurs répertoriés comme ayant SystemAccount=false. Le soufflet à une doublure atteint ce

grep SystemAccount=false /var/lib/AccountsService/users/* | awk -F '/' '{gsub(":","/");print $6}'

En rejoignant le parti, je supervise un système de réseau utilisant LDAP, ayant des répertoires personnels à l'extérieur /homeet des UID (en raison d'un problème de script) par millions. Aucune des réponses actuelles ne fonctionne donc. Le test qui fonctionne pour moi consiste à vérifier si l'utilisateur a un shell de connexion valide. Un shell valide est celui qui est répertorié dans /etc/shells. La forme la plus simple:

getent passwd | grep -wFf /etc/shells

Le fichier peut contenir des commentaires (ou des lignes vides), il peut donc être nécessaire de les filtrer:

getent passwd | grep -wFf <(grep '^/' /etc/shells)

Sur les systèmes buntu, les utilisateurs réguliers (utilisateurs humains, c'est-à-dire) ont des UID commençant par 1000 qui leur sont attribués de manière séquentielle lors de la première création de leurs comptes. Tout cela revient à dire que le premier compte créé sur un système buntu a un UID de 1000. Le suivant créé a un UID de 1001. Et ainsi de suite et ainsi de suite.

Donc, à mon avis, la façon la plus simple de répertorier tous les comptes d'utilisateurs humains présents sur le système est de vérifier si la troisième colonne du /etc/passwdfichier qui contient l'UID de l'utilisateur est supérieure ou égale à 1000 et inférieure à, disons, 2000 (il est très peu probable qu'un PC de bureau typique ait plus d'un millier de comptes d'utilisateurs, ne pensez-vous pas?):

$ awk -F$':' '{ if ($3 >= 1000 && $3 < 2000) print $1; }' /etc/passwd