Pourquoi rm est-il autorisé à supprimer un fichier appartenant à un autre utilisateur?
De la publication Pourquoi rm peut-il supprimer des fichiers en lecture seule? Je comprends que rm a juste besoin d'une autorisation d'écriture sur le répertoire pour supprimer le fichier. Mais j'ai du mal à digérer le comportement où l'on peut facilement supprimer un fichier dont le propriétaire et le groupe sont différents.
J'ai essayé ce qui suit
mtk: mon nom d'utilisateur
abc: a créé un nouvel utilisateur
$ ls -l file
-rw-rw-r-- 1 mtk mtk 0 Aug 31 15:40 file
$ Sudo chown abc file
$ Sudo chgrp abc file
$ ls -l file
-rw-rw-r-- 1 abc abc 0 Aug 31 15:40 file
$ rm file
$ ls -l file
<deleted>
Je pensais que cela n'aurait pas dû être autorisé. Un utilisateur doit pouvoir supprimer uniquement les fichiers dont il est propriétaire? Quelqu'un peut-il expliquer pourquoi cela est autorisé? et comment éviter cela? Je ne peux penser qu'à restreindre l'autorisation d'écriture du répertoire parent pour interdire les suppressions de fichiers surprises.
La raison pour laquelle cela est autorisé est liée à ce que fait réellement la suppression d'un fichier. Conceptuellement, le travail de rm consiste à supprimer une entrée de nom d'un répertoire. Le fait que le fichier puisse alors devenir inaccessible s'il s'agissait du seul nom du fichier et que l'inode et l'espace occupé par le fichier puissent donc être récupérés à ce stade est presque accessoire. Le nom de l'appel système que la commande rm appelle, qui est unlink, suggère même ce fait.
Et, supprimer une entrée de nom d'un répertoire est fondamentalement une opération sur ce répertoire , donc ce répertoire est la chose dont vous avez besoin d'avoir la permission d'écrire.
Le scénario suivant peut-il le rendre plus confortable? Supposons qu'il existe des répertoires:
/home/me # owned and writable only by me
/home/you # owned and writable only by you
Et il y a un fichier qui m'appartient et qui a deux liens durs:
/home/me/myfile
/home/you/myfile
Peu importe comment ce lien dur /home/you/myfile y est arrivé en premier lieu. Peut-être que root l'a mis là.
L'idée de cet exemple est que vous devez être autorisé à supprimer le lien dur /home/you/myfile. Après tout, cela encombre votre répertoire . Vous devriez pouvoir contrôler ce qui existe et n'existe pas à l'intérieur de /home/you. Et lorsque vous supprimez /home/you/myfile, notez que vous n'avez pas réellement supprimé le fichier. Vous n'y avez supprimé qu'un seul lien.
Notez que si le bit collant est défini sur le répertoire contenant un fichier (apparaît comme t dans ls), alors vous faites doit être le propriétaire du fichier pour pouvoir le supprimer (sauf si vous êtes propriétaire du répertoire). Le bit collant est généralement défini sur /tmp.
Pour supprimer un fichier, il vous suffit de pouvoir écrire dans le répertoire où se trouve le fichier.
Si vous n'aimez pas cela, vous pouvez définir le bit "collant" via chmod +t dir si vous utilisez un système d'exploitation récent (cette fonctionnalité a été introduite vers 1986 dans SunOS).
Si vous souhaitez être plus fin, vous avez besoin d'un système de fichiers avec une implémentation ACL moderne comme ZFS. Les listes de contrôle d'accès NFSv4 standard basées sur NTFS incluent la prise en charge des autorisations de suppression spécifiques aux fichiers par utilisateur et une autorisation "delete_child" pour les répertoires.
La logique est similaire à celle d'une maison: le propriétaire ou le locataire décide quels invités rejeter, quel que soit le propriétaire des invités. De plus, l'invité expulsé qui est le bienvenu dans une autre maison (a un autre lien physique dans le répertoire de quelqu'un d'autre) ne gèlera pas à l'extérieur.