J'ai fait quelques tests et je peux offrir une réponse (espérons-le) faisant autorité.
Réponse courte: les versions sont stockées sur le même disque (ou image disque) que le fichier réel, de sorte que les versions ne doivent pas divulguer d'informations en dehors de votre image cryptée. Mais il pourrait y avoir une autre fuite, voir ci-dessous.
Réponse longue: Versions crée un dossier invisible en haut de chaque volume, nommé ".DocumentRevisions-V100" avec une structure interne comme celle-ci:
.DocumentRevisions-V100
.cs
ChunkStorage (this is presumably used to store chunks of large files that didn't entirely change between versions)
AllUIDs (this is only created on disks that have permissions ignored)
ChunkTemp
db-v1
db.sqlite (this is the primary index of document IDs, etc)
PerUID (this is only created on disks that have ownership respected)
501 (documents created/owned by user #501)
502 (etc...)
staging (???)
Pour plus d'informations sur l'index sqlite et le démon d'arrière-plan qui en assure l'accès, lisez l'excellente critique de John Siracusa sur ars technica .
Les versions des documents elles-mêmes sont stockées dans des sous-répertoires dans AllUIDs ou PerUID / youruserid. Sous cela, chaque document versionné obtient son propre sous-répertoire, numéroté à partir de 1. Sous c'est un dossier unique nommé "com.apple.documentVersions", et sous cela, chaque révision est stockée en tant que document séparé (sauf s'il est divisé en morceaux - - Je n'ai pas testé de gros documents) nommés avec un UUID et une extension de type. Par exemple, si je (utilisateur # 501) édite un document rtf sur mon volume de démarrage et enregistre plusieurs révisions, elles peuvent être stockées comme:
/.DocumentRevisions-V100/PerUID/501/1/com.apple.documentVersions/0787B7C3-DE11-4065-9FD9-61870212011D.rtf
/.DocumentRevisions-V100/PerUID/501/1/com.apple.documentVersions/D533CF36-0D49-4910-B0EB-C92395C05726.rtf
Si j'ai ensuite ouvert un autre fichier rtf et enregistré une version de celui-ci, il pourrait être nommé:
/.DocumentRevisions-V100/PerUID/501/2/com.apple.documentVersions/74A6EF6E-A22A-4196-B560-40ABDBF46DF4.rtf
Si je l'ai enregistré sur mon image SecretDocs (montée avec la propriété ignorée), les versions seraient stockées comme:
/Volumes/SecretDocs/.DocumentRevisions-V100/AllUIDs/1/com.apple.documentVersions/2ED4DAFD-9BCF-4158-BFDB-F9EEC631E44A.rtf
BTW, les autorisations sur les fichiers de version semblent être clonées à partir des fichiers d'origine. Les autorisations sur les dossiers qui les entourent ont tendance à autoriser l'exécution uniquement (c'est-à-dire que vous ne pouvez pas voir les noms de fichiers, mais si vous connaissez le nom du fichier, vous pouvez y accéder). Par exemple, PerUID / 501 est défini pour autoriser l'exécution uniquement pour l'utilisateur 501, aucun accès pour quiconque. Le dossier db-v1 n'autorise que l'accès root. Sans enquêter en détail, il semble être assez verrouillé.
Maintenant, à propos de cette autre fuite dont je vous menaçais: les applications Lion ont tendance à enregistrer leur état lorsque vous quittez, donc si vous avez un document confidentiel ouvert lorsque vous quittez, certaines de ses informations (comme je pense qu'une capture d'écran) peuvent être stockées dans ~ / Library / Saved Application State / someappid.savedState. Tant que vous fermez avant d'enregistrer, je pense que vous êtes en sécurité ici.
Une excellente question de Phil M!
Les données relatives aux versions d'Apple ne sont parfois pas limitées à /.DocumentRevisions-V100
Je serai aussi bref que possible. Concepts clés:
Dans certaines circonstances,
- https://discussions.apple.com/message/15739595#15739595 (2011-07-25)
Aussi, légèrement adapté de https://discussions.apple.com/message/15741724#15741724
Dans mon test le plus récent avec le même serveur AFP, les versions pour une capture d'écran .png à distance:
sont locaux et correctement cachés
~/Library
… veuillez consulter la sauvegarde automatique, les versions, le CV et le Transparent App Lifecycle (TAL): informations techniques émergentesne sont pas localement à
/.DocumentRevisions-V100
ne sont pas à distance
/.DocumentRevisions-V100
…
Localement il pourrait y avoir des données associées à ,
/.DocumentRevisions-V100
mais dans ce cas, les versions du fichier distant sont locaux, et non limité à l'utilisateur root. Voir par exemple la capture d'écran 001 sur http://www.wuala.com/grahamperrin/public/2011/07/25/e/?mode=gallery illustrant les versions locales du fichier distant, ouverte après la déconnexion du serveur de fichiers.Retour à la question d'ouverture ici dans Ask Different… images cryptées .sparsebundle, sécurité. Considère ceci:
Dans le contexte d'une image de disque groupée clairsemée, les utilisateurs sont plus susceptibles d'utiliser JHFS + (prenant en charge le stockage de version permanente) que MS-DOS (manquant de prise en charge)
Cependant: quelqu'un devrait tester pour voir si les versions non chiffrées restent dans le répertoire personnel de l'utilisateur - qui peut être non chiffré - après qu'un volume tel que celui-ci soit démonté.
Personnellement, je trouve fseventer très utile dans des situations de test comme celle-ci. YMMV.
Séparation
Certaines de ces réponses peuvent soulever des questions qui ne sont pas spécifiques au chiffrement, non spécifiques aux images de disque groupées clairsemées, non spécifiques à la sécurité. Ce sont des sujets potentiellement complexes, alors s'il vous plaît: plutôt que de poser des questions dans les commentaires sous cette réponse, je devrais probablement encourager chaque question à être posée séparément.
la source
J'ai vérifié la documentation du développeur d'Apple sur la fonctionnalité des versions et cela semble indiquer que les versions précédentes d'un document sont stockées au même «endroit» (c'est-à-dire le même fichier ou le même dossier) que la version actuelle du document; mais la documentation manque de détails.
Il y a aussi l'article d'AppleInsider intitulé "Inside Mac OS X 10.7 Lion: sauvegarde automatique, versions de fichiers et Time Machine" , qui dit:
Je n'ai pas encore trouvé de description plus détaillée du fonctionnement de la fonction Versions.
la source
.DocumentRevisions-V100
(et non dans le même fichier que le document)Gordon, c'est une bonne nouvelle pour tout le monde, ainsi que pour les développeurs de logiciels pour Knox et Espionage (j'utilise ces deux applications).
Voici un scénario auquel les utilisateurs doivent faire attention cependant. Si vous accédez à un fichier dans une image disque chiffrée montée sur un lecteur externe, les fichiers de version existeront probablement sur le lecteur système de l'utilisateur sous une forme non chiffrée. Une solution consiste à copier le .sparsebundle sur le lecteur système avant de le monter.
Un autre scénario est si le fichier .sparsebundle se trouve sur un autre Mac Snow Leopard sur le même réseau et que l'image est partagée sur le réseau, ce qui permet le montage sur un Mac Lion en y accédant via le Finder. (Je le fais parfois.) Cela entraînerait certainement la mise en place de fichiers de version sur le disque système de l'utilisateur sous forme non cryptée. Une solution consiste à utiliser le partage d'écran pour contrôler le Snow Leopard Mac, puis à monter et à travailler dans l'image sur ce Mac.
L'essentiel, c'est que dans Lion, les gens ont besoin de mieux comprendre et d'être plus prudents que jamais lorsqu'ils utilisent des images de disque chiffrées si les images ne se trouvent pas sur le lecteur système. J'espère que les développeurs de Knox et Espionage avertiront leurs clients de ces problèmes.
EDIT: La réponse de Graham semble soutenir la plupart de mes hypothèses.
la source
.DocumentRevisions
sur le volume chiffré . @ La réponse de Gordon semble également le confirmer.