Windows n'utilise rien d'aussi primitif qu'un tas de chiffres pour représenter les permissions. Sur Lunix, chmod 777 définit les permissions pour être lu, écrit, exécutable par tout le monde. Les permissions Unix fonctionnent assez simplement, mais c'est une merde d'homme des cavernes pour les environnements complexes modernes. Windows utilise des permissions réelles et des utilisateurs réels avec une liste de contrôle d'accès attachée à tout objet (pas seulement les fichiers). Une liste de contrôle d'accès permet des autorisations plus granulaires et plus étendues qu'un simple masque de bits de drapeaux.
D'abord, faites un clic droit sur le fichier avec lequel vous avez l'intention de travailler. Dans la capture d'écran ci-dessous, suivez les flèches violettes pour ajouter le compte "Everyone" au fichier (j'ai utilisé la connexion anonyme comme exemple, tapez "everyone" dans le champ, puis appuyez sur vérifier les noms). Une fois ajouté, suivez la flèche verte. Cliquez sur Everyone, puis sur "full control".
Vous avez remarqué dans la capture d'écran que certains des noms sont précédés de Kraken ? Ce sont des groupes locaux. Ils appartiennent à ma machine. Kraken est le nom de ma machine et l'autorité d'authentification. Un ordinateur sur un domaine réseau possède à la fois des groupes de domaine et des utilisateurs de domaine. La plupart des ordinateurs d'un domaine n'ont pas d'utilisateurs locaux autres que les comptes de service. Dans le cas d'un domaine, les noms ressembleront à "DomainUser". Le domaine, avant la barre oblique, est l'autorité d'authentification. L'utilisation de groupes et de comptes de domaine vous permet de fournir un accès granulaire à des comptes réseau individuels, même si votre ordinateur n'a jamais interagi avec cet utilisateur.
Les droits d'interdiction ont la priorité sur les droits d'autorisation ! Ainsi, si vous donnez des droits " allow " pour un contrôle total à " Everyone " mais que " DomainKaren " a des droits deny, Karen sera refusée. Ne refusez pas l'accès à Everyone en pensant qu'il s'agit d'un compte anonyme. Peu importe le nombre de droits "allow" que vous avez pour des utilisateurs spécifiques, si vous refusez Everyone, vous avez effectivement mis ce fichier dans le vide.
L'ACL dans cet exemple est stockée directement dans le système de fichiers. Si vous partagez un fichier sur le réseau, le partage réseau possède une ACL unique, séparée et indépendante. Vous pouvez refuser un utilisateur par le réseau, mais lui autoriser l'accès s'il est connecté localement. La liste de contrôle d'accès locale a la priorité sur la liste de contrôle d'accès réseau. Si votre ACL locale refuse "DomainUsers" mais autorise "LocalBill", alors Bill pourra accéder au fichier puisque son compte est local, même sur le réseau.
Les ACL sont également héritées. Un fichier dans un répertoire, initialement, a la même ACL que le répertoire - jusqu'à ce que vous le changiez. Dans la plupart des cas de navigation dans les fichiers à l'aide d'une application, avant de pouvoir accéder à un fichier, vous devez pouvoir accéder au répertoire dans lequel il se trouve. Si vous pouvez accéder directement au fichier cela ne s'applique pas mais les droits par défaut seront toujours un problème potentiel.
Les ACL s'appliquent à tout objet, pas seulement aux fichiers. Une clé de registre est un objet, obvs, un fichier Lunix ini ne peut pas fournir une ACL séparée à chaque ligne unique du fichier, Windows le fait.
La ligne de commande pour travailler avec les ACL du système de fichiers est icacls (je vois les ACL). La ligne de commande pour travailler avec les ACL réseau est "net share sharename /grant" qui n'utilise pas l'ensemble des fonctionnalités des ACL disponibles.