Pourquoi un nouvel utilisateur a-t-il hérité des fichiers d'un utilisateur supprimé?

J'ai donc dû faire un exercice dans un livre comme devoirs. Vous devez d'abord créer un utilisateur comme:

useradd -c "Steven Baxter" -s "/bin/sh" sbaxter

Ensuite, vous avez dû ajouter des fichiers dans le /home/sbaxterrépertoire:

touch /home/sbaxter/ some.txt new.txt files.txt

Ensuite, vous deviez supprimer l' sbaxterutilisateur et créer un nouvel utilisateur nommé mjane. À ma grande surprise lorsque j'ai couru find /home/ -user mjane, le nouvel utilisateur mjanepossédait maintenant tous les anciens fichiers de sbaxter, que s'est-il passé?

users administration

— John
source

Le diable est dans les détails, dans la useraddpage de manuel (vous pouvez le voir en publiant man 8 useradd):

   -u, --uid UID
       The numerical value of the user's ID. This value must be unique,
       unless the -o option is used. The value must be non-negative. The
       default is to use the smallest ID value greater than or equal to
       UID_MIN and greater than every other user.

Par conséquent, il utilisera par défaut le plus petit uid inutilisé, qui est plus grand que les autres utilisateurs, dans le fichier de mot de passe. Étant donné que la suppression de sbaxter l'a supprimé du fichier passwd, son uid est "gratuit" et est attribué à mjane (car le useraddchoix de l'uid est le même pour les deux utilisateurs au moment où la useraddcommande a été utilisée).

Les fichiers sur le disque stockent uniquement l'uid, et NON la traduction du nom d'utilisateur (car cette traduction est définie dans le fichier de mot de passe). Vous pouvez le confirmer en émettant ls -lnpour voir quels sont les fichiers de propriété uid.

Je vous recommande en fait de désactiver plutôt que de supprimer des comptes. Le verrouillage des comptes sur la plupart des distributions Linux peut être réalisé avec usermod -L -e today <username>, ce qui verrouille le mot de passe et définit le compte pour expirer aujourd'hui (vous pouvez voir la date d'expiration d'un compte avec chage -l).

— Drav Sloan
source

... cela semble être une faille de sécurité terrible. Existe-t-il un moyen de contourner ce problème?

— BlueRaja - Danny Pflughoeft

@ BlueRaja-DannyPflughoeft Ce n'est pas une faille de sécurité: les utilisateurs sont identifiés par leur ID utilisateur, pas par leur nom d'utilisateur. Lorsque vous supprimez un compte, vous devez supprimer tous ses fichiers (c'est-à-dire tous les fichiers appartenant à cet ID utilisateur, pas seulement le répertoire personnel de l'utilisateur). Cela fait partie de la procédure normale pour supprimer un compte.

— Gilles 'SO- arrête d'être méchant'

@OlivierDulac Cela s'appelle une sauvegarde. Alternativement, verrouillez mais ne supprimez pas le compte tant que vous devez conserver ses données. Après tout, si vous devez conserver les données, le compte est toujours nécessaire.

— Gilles 'SO- arrête d'être méchant'

Le verrouillage des comptes sur la plupart des distributions Linux peut être réalisé avec usermod -L -e today <username>, ce qui verrouille le mot de passe et définit le compte pour expirer aujourd'hui (vous pouvez voir la date d'expiration d'un compte avec chage -l).

— Drav Sloan

C'est une faille de sécurité, selon les normes actuelles. Comme le montre l'exemple, cela signifie que vous ne pouvez pas associer des humains à des fichiers. Bien sûr, les humains peuvent être fortement associés aux comptes, mais le fichier d'association humain <-> compte <-> tombe en panne en raison du recyclage de l'UID. Là encore, Unix n'a jamais eu une grande sécurité à cet égard (il rootpouvait simuler presque n'importe quoi). Vous avez besoin de pistes d'audit pour cela.

— MSalters

L'UID de l'utilisateur supprimé a été réutilisé par le nouvel utilisateur, et les systèmes de fichiers utilisent un UID pour la propriété, pas un nom d'utilisateur.

— Ignacio Vazquez-Abrams
source