Comment contourner le défaut de conception NTFS Move / Copy?

31

Comme le savent tous ceux qui ont traité des autorisations de serveur de fichiers, NTFS a une fonctionnalité / faille de conception intéressante connue sous le nom de problème de déplacement / copie.

Comme expliqué dans cet article MS KB , les autorisations pour un dossier ou un fichier n'héritent pas automatiquement du parent si le dossier est déplacé et que la source et la destination se trouvent sur le même volume NTFS. Les autorisations sont héritées si le dossier est copié ou si la source et la destination se trouvent sur des volumes différents.

Voici un petit exemple:

Vous avez deux dossiers partagés sur le même volume NTFS appelés "Techniciens" et "Gestionnaires". Le groupe Techniciens a un accès RW au dossier Techniciens et le groupe Managers a un accès RW au dossier "Managers". Si quelqu'un a accès aux deux et déplace un sous-dossier du dossier "Managers" vers le dossier "Technicians", le dossier qui est déplacé n'est toujours accessible qu'aux utilisateurs du groupe "Managers". Le groupe "Techniciens" ne peut pas accéder au sous-dossier même s'il se trouve sous le dossier "Techniciens" et doit hériter des autorisations par le haut.

Comme vous pouvez l'imaginer, cela entraîne des appels de support, des tickets et des cycles inutiles pour résoudre ces problèmes d'utilisateur final, sans parler du nid de rats d'autorisations que vous pouvez vous retrouver si les utilisateurs déplacent souvent des dossiers entre différents dossiers / zones sécurisés sur le même volume.

Les questions sont:

Quelle est la meilleure façon de contourner cette faille de conception NTFS et comment la gérez-vous dans votre environnement?

Je sais que l'article de la base de connaissances lié parle de certaines clés de registre pour modifier le comportement par défaut de l'Explorateur Windows, mais elles sont côté client et nécessitent que les utilisateurs aient la possibilité de modifier les autorisations, ce que je pense dans la plupart des environnements, ce n'est pas un démarreur si vous souhaitez garder le contrôle sur les autorisations de votre serveur de fichiers (et votre santé mentale en tant qu'administrateur système).

— David Archer
source

2

Je sais que l'exemple des gestionnaires / techniciens est juste pour illustrer la faille, mais dans certains cas, c'est le comportement que vous souhaitez: si quelqu'un déplace accidentellement le dossier des gestionnaires aux techniciens, vous ne voulez probablement pas que les techniciens puissent accéder il.

— Ward - Rétablir Monica

2

Ce n'est vraiment pas un défaut, c'est la façon dont les autorisations de fichiers fonctionnent. Il a été documenté depuis la sortie de NTFS. Je ne peux pas croire que certaines personnes recommandent de ne pas utiliser les autorisations de fichier et d'utiliser uniquement l'autorisation de partage pour contrôler l'accès. Cela va à l'encontre des principes de base de la sécurité d'un serveur de fichiers Microsoft. La raison pour laquelle le déplacement d'un dossier / fichier sur le même volume n'hérite pas est que le dossier / fichier ne se déplace pas réellement sur le disque, juste le pointeur que nous voyons changer.

— Michael Brown

12

Mon approche consiste à ne pas utiliser les autorisations de fichier au niveau du fichier / répertoire; utiliser les autorisations au niveau du partage de fichiers et définir le lecteur de données du système de fichiers du serveur entier sur Tout le monde (qui devient théorique).

Au fil des ans (10+), j'ai constaté que les autorisations NTFS sont plus complexes et entraînent plus d'erreurs. Si les autorisations sont mal définies ou si l'héritage est rompu, vous exposez les données et leur difficulté à les trouver et à les voir. De plus, vous êtes exposé au problème de déplacement / copie comme vous le dites.

Emplacements où vous devez utiliser les ACL de niveau répertoire / fichier; Je ne connais pas d'autre solution que de vérifier régulièrement la santé de la chose.

— James Risto
source

10

Et bien ce n'est pas vraiment un défaut. Cette règle de gestion des autorisations lors du déplacement de fichiers est en place depuis au moins la bêta 2 de NT3.1 (bien que ce ne soit évidemment pas un héritage car cela n'a été ajouté qu'avec Windows 2000). C'est à peu près aussi bien connu que n'importe quelle fonctionnalité de Windows. J'ai beaucoup de sympathie pour votre point de vue, car il peut y avoir peu d'entre nous qui n'ont pas été brûlés par cela à un moment donné. Mais c'est quelque chose que l'administrateur système apprend rapidement.

JR

— John Rennie
source

6

J'ai eu une discussion avec Raymond Chen sur son blog à ce sujet. Microsoft "vend" NTFS comme ayant "l'autorisation" d'héritage ", puis recule lorsque cette faille particulière dans l'armure est évoquée. NTFS dispose d'un héritage d'autorisation au moment de la création du fichier en plaçant des ACE explicites sur les fichiers lors de leur création. Je dirais que, tant que la documentation et la documentation marketing parlent de leur système d'héritage comme si c'était en temps réel, la documentation ou le code était bogué. Ils devraient en choisir un et le réparer.

— Evan Anderson

1

Eh bien, c'est un compromis. Si l'héritage était en temps réel, chaque fois que vous ouvrez un fichier au bas d'une arborescence profonde, le système d'exploitation doit exécuter l'arborescence pour savoir quelles sont les autorisations effectives. Bien sûr, le compromis est que si vous modifiez les autorisations en haut d'un arbre profond, vous avez une attente longue! Active Directory n'utilise-t-il pas le même modèle?

— John Rennie

Les objets AD héritent correctement des autorisations du nouveau parent lorsqu'ils sont déplacés entre les conteneurs et je dirais que c'est le comportement "correct" attendu lors du déplacement de fichiers / dossiers dans NTFS.

— David Archer

3

@renniej: AD utilise un véritable héritage en temps réel. Le système de fichiers Netware l'a fait il y a longtemps. NTFS aurait pu le faire aussi si Microsoft l'avait mis en œuvre. C'est la "route non empruntée". Ce qui m'énerve, c'est que la documentation de Microsoft concernant NTFS et l'Explorateur "joue" comme l'héritage est en temps réel (c'est-à-dire des mensonges). Dites-le nous tel quel, ou corrigez le comportement pour empanner avec la documentation!

— Evan Anderson

@renniej Comme Evan Anderson l'a dit, Netware a fait cela en 1990 quand ils étaient roi. Le problème peut être résolu en créant un autre index du système de fichiers qui suit la «liste de visibilité». Microsoft a choisi de ne pas le faire, mais pourrait en concevoir un pour une future version de Windows Server.

— sysadmin1138

6

Nous utilisons NTFS depuis NT 3.51 et bien que nous ayons vu ce "problème" (comme presque tout le monde), cela ne nous a pas posé beaucoup de problèmes:

Nous demandons toujours aux gens de copier des fichiers s'ils ont besoin de les déplacer d'un répertoire partagé à un autre. "Maintenez la touche CTRL enfoncée lorsque vous faites glisser et assurez-vous que le petit + s'affiche", est une expression courante.
Nos dossiers partagés ont une structure assez simple, et les dossiers partagés que nous créons ne se croisent pas trop souvent entre les groupes, donc les gens sont plus susceptibles de vouloir copier des fichiers en premier lieu.
Nous voyons le problème principalement dans notre espace "commun" - des dossiers où tout le monde peut lire / écrire, mais ces répertoires sont pour la plupart de courte durée, donc le problème disparaît lorsqu'ils sont purgés.

— Quartier - Réintégrer Monica
source

4

Solutions de contournement auxquelles je peux penser:

trouver un moyen de créer des dossiers avec des autorisations différentes sur des volumes NTFS différents
Effectuez une tâche planifiée (une fois par heure ou une fois par jour en fonction de la fréquence des demandes d'assistance) qui parcourt les dossiers et réinitialise toutes les autorisations pour qu'elles soient identiques à celles du niveau supérieur. C'est loin d'être idéal, d'autant plus si les dossiers contiennent de nombreux fichiers, mais c'est quelque chose qui permettrait de résoudre le problème s'il n'y a pas de bonne solution, comme un correctif de registre côté serveur. La commande que vous voudrez regarder s'appelle «cacls» que vous pouvez ensuite ajouter à un fichier batch.

Avis de non-responsabilité - Je viens d'un arrière-plan Unix (et j'ai mis en œuvre le dernier pour corriger différentes failles d'autorisations - cela semble icky, mais fait le travail), donc il peut y avoir une bien meilleure solution.

— marque
source

+1 - La 1ère réponse donnée par Mark est le meilleur choix. C'est une douleur, mais c'est votre meilleur moyen de contourner cette décision de conception stupide dans NTFS 5.

— Evan Anderson

Pour développer: C'est un endroit où mes copains utilisant SharePoint diraient "utiliser SharePoint"! De même, mes copains utilisant le contrôle de version et les copains utilisant le système de contrôle de document pointeraient vers Subversion, Documentum, etc., et diraient «utilise ça». Ce choix de conception dans NTFS est une énorme verrue énorme, et cela vous fait presque vous demander si Microsoft UTILISE réellement son propre logiciel lorsque vous devez vous battre avec lui dans votre propre réseau. (Cela me crie que Microsoft n'utilise pas leurs logiciels de la même manière que nous le faisons avec nos utilisateurs, en fait. Ça doit être bien d'avoir une entreprise remplie avec des "travailleurs du savoir".)

— Evan Anderson

1

Je suis d'accord que, dans l'idéal, nous pourrions séparer tous les dossiers partagés sur leurs propres volumes, en pratique, cela ne fonctionne pas pour un grand environnement (des milliers de dossiers partagés). En outre, sans point de jonction génial ou vaudou symlink, cela signifie perdre la possibilité d'avoir des sous-dossiers imbriqués avec différentes autorisations sur eux.

— David Archer

1

@David: le déplacement des données entre les partages entraînera une copie et une suppression. Le déplacement de données dans un partage entraînera un déplacement. Si vous faites de chaque dossier partagé la racine d'une hiérarchie d'autorisations sans qu'aucun sous-dossier n'ait une autorisation plus restrictive, vous atténuerez le problème. Toujours moche, cependant. (J'ai un serveur W2K3 avec plus de 2200 dossiers partagés individuels et je ne vois pas de problèmes de performances ...)

— Evan Anderson

3

Lorsque je me déplace en tant qu'administrateur, j'utilise xcopy / s / e / c / h / r / k / y - tout sauf la propriété du fichier et ACL, ce qui signifie que l'héritage ACL entre automatiquement en jeu. Je n'ai jamais vraiment eu à faire face à une situation où un utilisateur déplacé des choses cependant.

— Maximus Minimus
source

2

Vos utilisateurs sont-ils vivants?

— Evan Anderson

4

Parfois je me demande ...

— Maximus Minimus

@Even: Peut-être qu'aucun d'entre eux n'est dans deux groupes!

— SamB

+1 pour diriger les utilisateurs vers l'outil qui résout ce problème lors de la maintenance des fichiers (ainsi que de nombreux autres); cependant, XCOPY a été déprécié: ROBOCOPY.EXE est son successeur très compétent.

— jnaab

2

Désolé pour la sélection, mais xcopy _copy_ les fichiers (au lieu de _moving_ les fichiers?) - il semble que l'auteur n'a aucun problème avec la copie, il a seulement des problèmes avec _moving_. Je peux me tromper sur ce bc de mon manque d'expérience, alors corrigez-moi si je me trompe (c'est-à-dire utilisez-vous la commande 'del' après avoir utilisé 'xcopy', alors les fichiers sont en fait 'copiés et supprimés'! = déplacé?)

— colemik

3

J'utilise la stratégie de groupe / les politiques de sécurité / le système de fichiers pour suivre les autorisations compliquées. (N'utilisez JAMAIS les "autorisations de remplacement" dans la stratégie).

Planifiez un CACLS pour réinitialiser toutes les autorisations pendant la nuit, suivi d'un gpupdate / force pour réappliquer l'autorisation de la stratégie. Fonctionne comme un charme.

— Alexandru Nica
source

Vraisemblablement, ce n'est que pour les serveurs Windows? Comme la stratégie de groupe doit être appliquée aux objets de domaine, cela ne pourrait pas être appliqué aux partages de stockage non Windows, j'imagine?

— Rich M

2

Depuis Windows 7 (ou peut-être Windows Vista), les autorisations pour un dossier ou un fichier héritent du parent si le dossier est déplacé et la source et la destination se trouvent sur le même volume NTFS - si un fichier ou un dossier est copié via l'Explorateur. Dans un système d'exploitation antérieur, vous pouvez utiliser Far Manager - il permet d'activer l'héritage des autorisations de la destination (avec des tonnes d'autres fonctionnalités). Bien que Far puisse sembler peu convivial pour un utilisateur général.

— GCRaistlin
source

0

Une solution de contournement très simple consiste à compresser simplement les fichiers et à les décompresser dans le répertoire de destination.

— Bob
source

Je viens d'essayer cela et malheureusement cela n'a pas fonctionné. Les autorisations sur l'archive zip sont différentes avant même que j'aie fait quoi que ce soit avec. Les autorisations héritées restent mais celles explicites ne sont pas créées.

— Rich M