2009-05-08 6 views
6

Notre application utilise un composant qui nécessite un fichier de licence dans le répertoire avec notre exécutable, qui se trouve être une application .NET WinForms si je pense que cela n'a pas d'importance à cette question. Lorsqu'il est installé sur certaines machines XP Pro (seulement trois sur plusieurs centaines jusqu'à présent), le composant lève une exception de licence. J'ai donc régénéré le fichier de licence et l'ai envoyé au fournisseur de composants (EMC Captiva), où le vendeur prétend que l'erreur est due au fait que le groupe "Utilisateurs" n'a pas d'autorisations de lecture sur le fichier. L'utilisateur qui rencontre l'erreur se trouve être un administrateur local, mais c'est d'ailleurs le point car je suis toujours curieux de la question plus générale. Donc ma question est, les ACL sont-ils stockés dans un fichier de telle sorte qu'ils suivent le fichier tout au long de sa vie, en particulier lorsque le fichier de licence a été généré sur ma machine dev (machine 1), stocké dans Subversion (machine 2), vérifié hors du contrôle de source par TeamCity (machine 3), empaqueté dans un installateur par InstallShield (machine 4), et finalement déployé sur la machine du client (machine 5) où il a été installé par un administrateur? Qu'en est-il après avoir généré le fichier sur ma machine de développement (machine 1), le télécharger vers le fournisseur de composants via leur site de support (machine 2), et la personne de support le télécharge pour inspection (machine 3)? Je ne le sais pas avec certitude (c'est pourquoi je le demande ici), mais j'ai supposé que chaque machine Windows stocke les listes de contrôle d'accès dans un répertoire/liste/table central géré par NTFS plutôt que stocké dans le fichier. Qu'arrive-t-il à la liste de contrôle d'accès du fichier d'origine lorsqu'elle est copiée d'une machine à une autre, stockée dans Subversion, empaquetée dans un fichier MSI, etc.? Quelqu'un peut-il me diriger vers de bonnes références où je peux lire à ce sujet?Où Windows stocke-t-il les ACL et les ACL suivent-ils un fichier d'une machine à l'autre?

+0

Qu'essayez-vous de faire? Qu'est-ce que l'emballage des ACL dans un paquet MSI serait bon? Vous ne pouvez pas contrôler ce que les gens font à un fichier une fois qu'il a quitté votre propre ordinateur, si c'est ce que vous avez en tête. – Tomalak

+1

Comme je l'ai dit: L'ACL * ne fait pas partie du fichier *. TortoiseSvn ne peut même pas voir la liste de contrôle d'accès. – Tomalak

+0

C'est ce que le fournisseur de composants semble suggérer, mais je ne l'achète pas. – flipdoubt

Répondre

13

Les listes de contrôle d'accès sont stockées dans la partie d'une partition NTFS qui exécute toute la plomberie d'arrière-plan, à savoir la table MFT (Master File Table). La liste de contrôle d'accès ne suit pas un fichier, car elle ne fait pas partie du fichier (tout comme le nom de fichier, il s'agit de méta-données). Le fichier peut traverser les limites de type de partition (NTFS-> FAT), ce qui n'est pas le cas pour l'ACL.

Maintenant, si vous déplacez un fichier dans une partition NTFS, vous pourriez avoir l'impression que les listes ACL suivent réellement le fichier. C'est parce que pendant un mouvement, seul le nom de fichier dans la MFT est réellement changé. Tout le reste demeure inchangé.

Si vous copiez un fichier ou le déplacez vers une autre partition ou un autre ordinateur (qui est en fait une opération de copie + suppression), le fichier copié héritera par défaut des autorisations de son nouveau conteneur (uniquement héritables).). Cependant, il existe des outils capables de conserver l'ACL d'un fichier après une opération de copie (simplement en le recréant sur le fichier cible après l'opération de copie) même sur des limites de partition ou d'ordinateur. xcopy peut le faire, entre autres. Mais comme une liste de contrôle d'accès peut contenir des identificateurs de domaine appartenant à un domaine, une entrée de liste de contrôle d'accès peut ne pas être significative pour l'ordinateur cible ne faisant pas partie du même domaine (par exemple, une clé USB NTFS).). Dans ce cas, l'entrée ACL n'aura aucun effet.

D'autres SID sont "bien connus", comme le SID "SYSTEM". Ceux-ci seront réellement reconnus à travers les frontières de domaine.

+0

+1 Vous avez dit exactement ce que j'allais dire .. :) – RobS

+0

Donc, vous êtes d'accord que le fournisseur de composants qui m'offre le support ne voit probablement pas la même ACL que l'utilisateur voit sur sa machine cible, n'est-ce pas? Aussi, pouvez-vous suggérer des ressources en ligne où je peux lire plus sur ce que vous avez dit? – flipdoubt

+1

Une vue d'ensemble: http://www.pcguide.com/ref/hdd/file/ntfs/secAccess-c.html – RobS

Questions connexes