Qui peut modifier les autorisations d'un fichier / répertoire?

Je crois (pas sûr) que le propriétaire d'un fichier / répertoire et l'utilisateur root sont les seuls utilisateurs autorisés à modifier les autorisations d'un fichier / répertoire. Suis-je correct ou y a-t-il d'autres utilisateurs qui sont également autorisés à modifier les autorisations?

files permissions

— user226341
source

Réponses:

Seul le propriétaire et le root(super utilisateur) sont autorisés à modifier l'autorisation d'un fichier ou d'un répertoire. Cela signifie que le propriétaire et le super utilisateur peuvent définir les autorisations read ( r), write ( w) et execute ( x). Mais changer la propriété (utilisateur / groupe) des fichiers et répertoires avec les commandes chown/ chgrpn'est autorisé qu'à root.

— Rakib
source

Le propriétaire d'un fichier peut modifier la propriété du groupe de ce fichier si l'utilisateur est membre du nouveau groupe.

— Kusalananda

Aux fins d'un fonctionnement normal, seuls root et le propriétaire peuvent chmod. En outre, root peut chownetchgrp , et en outre, le propriétaire peut chgrpaussi longtemps que le propriétaire est membre du groupe cible.

Pour des raisons de sécurité, il existe cependant un autre cas: tout utilisateur disposant d'une autorisation d'écriture dans le répertoire contenant le fichier peut remplacer le fichier par une copie et devenir ainsi le propriétaire, ce qui lui permet de modifier les autorisations et le contenu.

Ainsi:

14:14 mybox:~ mkdir mydir
14:14 mybox:~ cd mydir/
14:14 mybox:mydir echo foo | sudo tee yourfile
foo
14:14 mybox:mydir ls -ld . yourfile 
drwxr-xr-x  3 me    staff  102 Apr 11 14:14 .
-rw-r--r--  1 root  staff    4 Apr 11 14:14 yourfile

Nous avons créé un répertoire et écrit un fichier en tant que root. Étant donné que root possède le fichier, nous ne pouvons pas y écrire, ni chmod:

14:15 mybox:mydir echo bar > yourfile 
-bash: yourfile: Permission denied
14:15 mybox:mydir chmod a+x yourfile
chmod: Unable to change file mode on yourfile: Operation not permitted

Cependant, nous avons une autorisation d'écriture sur le répertoire, nous pouvons donc remplacer le fichier pour en devenir propriétaire:

14:15 mybox:mydir mv yourfile yourfile2
14:15 mybox:mydir cp yourfile2 yourfile
14:15 mybox:mydir ls -ld . yourfile 
drwxr-xr-x  4 me   staff  136 Apr 11 14:15 .
-rw-r--r--  1 me   staff    4 Apr 11 14:15 yourfile

Et maintenant que nous sommes le propriétaire, nous pouvons bien sûr faire ce que nous voulons avec ce fichier:

14:15 mybox:mydir echo bar > yourfile 
14:15 mybox:mydir chmod a+x yourfile
14:16 mybox:mydir cat yourfile
bar

De même, tout utilisateur disposant d'une autorisation d'écriture sur n'importe quel répertoire du chemin complet menant au fichier peut remplacer la structure du répertoire à partir de ce moment, obtenant ainsi la propriété du fichier avec le nom donné. La propriété ou les autorisations du fichier d'origine réel (que nous avons renommé «votrefichier2») ne sont bien sûr pas modifiées.

14:17 mybox:mydir ls -l yourfile2
-rw-r--r--  1 root  staff  4 Apr 11 14:14 yourfile2

— Basse
source

Savez-vous si une distribution Linux prend en charge des fonctionnalités de sécurité supplémentaires comme Windows? Si je suis sous Windows, je peux définir l'autorisation de suppression d'un fichier sur refusée pour empêcher la suppression même lorsque le répertoire est permissif.

— Kevin Li

De nombreuses versions Linux (la plupart?) Prennent en charge les listes de contrôle d'accès au niveau des fichiers, ( getfacl / setfacl) qui offrent plus de flexibilité que les autorisations de fichiers de style "classique". La suppression de fichiers dans * nix fonctionne en supprimant le lien vers le fichier du répertoire, donc la suppression du fichier est toujours contrôlée par les autorisations du répertoire; les autorisations de fichiers eux-mêmes n'y jouent aucun rôle.

— Bass

Très fidèle à la philosophie Unix de «tout est un fichier». Donc, vous dites qu'une telle chose ne peut pas être faite sous Linux?

— Kevin Li

@KevinLi Cette réponse n'est pas vraiment complète. Vous pouvez définir le bit collant sur un répertoire pour limiter la capacité des non-propriétaires à supprimer ou renommer des fichiers. Voir cette question et ses réponses: unix.stackexchange.com/questions/79395/… Il n'est pas nécessaire d'utiliser des ACL ou d'autres schémas.

— Andrew Henle

Les systèmes de fichiers @KevinLi * nix sont très différents de ceux de Windows. Les fichiers existent séparément de la hiérarchie des répertoires et ils peuvent avoir plusieurs "liens durs" pointant vers eux dans les répertoires. Supprimer un fichier signifie en fait supprimer le lien dur, ce qui se fait sur le répertoire. Le fichier garde une trace du nombre de liens durs pointant vers lui, et le fichier réel restera sur le disque tant qu'il y aura au moins un lien dur pointant vers lui. Ainsi, la suppression est contrôlée par les autorisations d'annuaire, qui faire une option spéciale pour autoriser uniquement par le propriétaire et supprime racine fichier, comme le dit Andrew.

— Bass

La chmodcommande appelle assez directement l'appel système du même nom; la page de manuel de l' chmod(2)appel système (sous Linux 4.10) indique:

L'UID effectif du processus appelant doit correspondre au propriétaire du fichier, ou le processus doit être privilégié (Linux: il doit avoir la CAP_FOWNERcapacité).

Si le processus appelant n'est pas privilégié (Linux: n'a pas la CAP_FSETIDcapacité) et que le groupe du fichier ne correspond pas à l'ID de groupe effectif du processus ou à l'un de ses ID de groupe supplémentaires, le S_ISGIDbit sera désactivé, mais cela ne provoquera pas le retour d'une erreur.

Donc, oui, un processus exécuté en tant que root peut modifier les autorisations de n'importe quel fichier s'il n'a pas abandonné la CAP_FOWNERcapacité.

Également intéressant est chown; la page de manuel de chown(2)dit:

Seul un processus privilégié (Linux: un avec la CAP_CHOWNcapacité) peut changer le propriétaire d'un fichier. Le propriétaire d'un fichier peut remplacer le groupe du fichier par tout groupe dont ce propriétaire est membre. Un processus privilégié (Linux: avec CAP_CHOWN) peut changer arbitrairement le groupe.

— Toby Speight
source