Où est le propriétaire du fichier sous Windows, vu qu'il y a des ACL?


12

Venant d'un arrière-plan Linux, je suis habitué à un fichier ayant un propriétaire et un groupe propriétaire. Les autorisations d'accès peuvent être définies séparément pour le propriétaire, le groupe et les autres, et c'est tout.

Maintenant sur Windows (basé sur NT), c'est un peu différent, car Windows utilise des ACL. Cela signifie qu'au lieu d'avoir trois listes d'autorisations (propriétaire, groupe, repos), je peux avoir autant de listes d'autorisations que je le souhaite.

Jusqu'à présent, cela a du sens. Cependant, pourquoi Windows a-t-il toujours la notion de propriétaire de fichier? Il me semble qu'avec les ACL, un "propriétaire de fichier" n'est plus nécessaire, car tous les accès peuvent être configurés via les ACL.

Alors pourquoi Windows moderne utilise-t-il toujours la propriété des fichiers? Où cela fait-il une différence à qui appartient un fichier? Tant que deux fichiers ont les mêmes ACL, la propriété des fichiers ne devrait pas avoir d'importance - ou non?


Principalement appliqué pour le réseautage ... les habitants utilisent l'UAC
Piotr Kula

3
@ppumkin: Windows UAC s'ajoute uniquement au système ACL.
user1686

@ppumkin: désactivez l'UAC, puis essayez de remplacer les fichiers dans System32. Les ACL vous arrêteront froid .
surfasb

Réponses:


10

Tout d'abord, Linux possède des ACL - POSIX ACL , qui permettent de définir les bits d'autorisation pour un nombre illimité d'utilisateurs et de groupes. (Les correctifs pour RichACL , ACL très similaires à NFSv4 et WinNT, ont été soumis à plusieurs reprises, mais pas encore fusionnés.)

La propriété peut être utilisée comme une sorte d'évasion de sécurité - le propriétaire peut toujours modifier les ACL de l'objet, même si la modification serait refusée autrement, par exemple, si quelqu'un a accidentellement supprimé toutes les entrées ACL ou refusé toutes les modifications à tout le monde. (Sous Linux, seul le propriétaire ou le superutilisateur peut modifier les ACL d'un fichier, car il n'y a pas d'autorisation distincte de "modifier les ACL".)

Une autre utilisation de la propriété de fichier, à la fois sur Windows NT et Linux, consiste à déterminer sur quel quota le fichier doit être compté, si des quotas de disque sont utilisés.


@surfasb En écho à son commentaire. Vraiment un bon argument pour "se soucier" de la propriété.
Erutan409

3

Il y a une grande différence si vous le regardez du point de vue d'un administrateur.

Sous Linux, root peut tout faire directement - le compte comme implicitement toutes les autorisations sur tous les objets du système de fichiers et au-delà.

Sous Windows, un administrateur n'est pas autorisé à tout faire par défaut - uniquement si vous êtes propriétaire de l'objet (fichier, entrée de registre de dossier, ...) que vous souhaitez modifier.

Prenons par exemple un dossier dont un administrateur a besoin pour modifier les autorisations de fichier. Si l'administrateur n'a pas l'autorisation de modifier les paramètres de sécurité du dossier, il doit prendre possession du dossier avant de pouvoir y accéder / le modifier.

Mise à jour:

Cette fonctionnalité est importante car dans un environnement contrôlé par ACL, il peut arriver qu'un fichier ait une ACL vide, ce qui signifie que personne n'a accès (principe de refus par défaut). Dans un tel cas, la prise de possession est le seul moyen d'accéder ou de supprimer le fichier.


1
Cela signifie-t-il que seul le propriétaire d'un fichier peut modifier ses autorisations? Ou pourquoi un administrateur peut-il s'approprier un fichier, mais ne peut pas modifier directement les autorisations?
sleske

Voir ma réponse mise à jour.
Robert

@sleske: Oui, le propriétaire d'un objet peut toujours modifier ses autorisations.
surfasb

2

Le propriétaire de l'objet peut toujours modifier les ACL.


1
Comment changez-vous l'ACL cependant?
Simon Sheehan

1
Utilisation de l'onglet de sécurité dans les propriétés.
kinokijuf
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.