I store sensitive information on my laptop in encrypted .sparsebundle images which are made with apps like Disk Utility, Knox and Espionage. The question is, if I upgrade to Lion, when I'm working on a file located in one of these mounted disk images and Lion is saving older versions of the file, are these older versions stored within the encrypted image (as they should be) or somewhere else? If the versions are stored somewhere else, are they encrypted or not?
4 Answers
I've done some testing, and can offer a (hopefully) authoritative answer.
Short answer: the versions are stored on the same disk (or disk image) as the actual file, so versions shouldn't leak information outside of your encrypted image. But there might be another leak, see below.
Long answer: Versions creates an invisible folder at the top of each volume, named ".DocumentRevisions-V100" with an internal structure like this:
.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 (???)
For info on the sqlite index and the background daemon that mediates access to it, read John Siracusa's excellent review at ars technica.
The document versions themselves are stored in subdirectories in either AllUIDs or PerUID/youruserid. Under that, each versioned document gets its own subdirectory, numbered starting at 1. Under that is a single folder named "com.apple.documentVersions", and under that, each revision is stored as a separate document (unless it's broken into chunks -- I haven't experimented with large documents) named with a UUID and type extension. For example, if I (user #501) edit a rtf document on my boot volume and save several revisions, they might be stored as:
/.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
If I then opened another rtf file and saved a version of it, it might be named:
/.DocumentRevisions-V100/PerUID/501/2/com.apple.documentVersions/74A6EF6E-A22A-4196-B560-40ABDBF46DF4.rtf
If I saved it on my SecretDocs image (mounted with ownership ignored), versions would be stored like:
/Volumes/SecretDocs/.DocumentRevisions-V100/AllUIDs/1/com.apple.documentVersions/2ED4DAFD-9BCF-4158-BFDB-F9EEC631E44A.rtf
BTW, permissions on the version files seem to be cloned from the original files. Permissions on the enclosing folders tend to allow execute only (i.e. you can't see the filenames, but if you know the file's name you can access it). For example PerUID/501 is set to allow execute only for user 501, no access for anyone else. The db-v1 folder only allows root access. Without investigating in detail, it seems to be pretty locked-down.
Now, about that other leak I threatened you with: Lion apps tend to save their state when you quit, so if you have a confidential document open when you quit, some of its information (like I think a screenshot) may get stored in ~/Library/Saved Application State/someappid.savedState. As long as you close before saving I think you're safe here.
-
What if the sparsebundle is located on an external disk (could be HFS, FAT or NTFS), or on a Snow Leopard machine on the network? Are the versions still stored on the same disk as the main file?– Phil MJul 29, 2011 at 20:04
-
I would like to set this answer as the accepted answer but I don't see the button, I don't know why.– Phil MAug 1, 2011 at 3:12
-
-
@raxacoricofallapatorius: I haven't fully confirmed this (the format of the info in the .savedState folder is not obvious), but I strongly suspect the leak is still there in 10.8. Feb 28, 2013 at 6:20
An excellent question from Phil M!
Data related to Apple versions is sometimes not limited to /.DocumentRevisions-V100
I'll keep this as brief as possible. Key concepts:
- Transparent App Lifecycle (TAL) — auto save, versions resume
- file systems support for permanent version storage.
In some circumstances,
… In 10.7 (Build 11A511): subdirectories of
~/Library
are used, with access not limited to the root user. …
— https://discussions.apple.com/message/15739595#15739595 (2011-07-25)
Also, slightly adapted from https://discussions.apple.com/message/15741724#15741724
In my most recent test with the same AFP server, the versions for a remote .png screenshot:
are local and within the properly hidden
~/Library
… please see auto save, versions, resume and the Transparent App Lifecycle (TAL): emerging technical informationare not locally at
/.DocumentRevisions-V100
are not remotely at
/.DocumentRevisions-V100
…
reunion:~ centrimadmin$ ls -ld /.DocumentRevisions-V100
ls: /.DocumentRevisions-V100: No such file or directory
Locally there might be some related data at /.DocumentRevisions-V100
but in this case, the versions of the remote file are local, and not limited to the root user. See for example screenshot 001 at http://www.wuala.com/grahamperrin/public/2011/07/25/e/?mode=gallery demonstrating the local versions of the remote file, opened after disconnecting from the file server.
Back to the opening question here in Ask Different … encrypted .sparsebundle images, security. Consider this:
In the context of an encrypted sparse bundle disk image, users may be more likely to use JHFS+ (supporting permanent version storage) than MS-DOS (lacking support)
However: someone should test to see whether unencrypted versions remain within the user's home directory — which may be unencrypted — after a volume such as that is unmounted.
Personally, I find fseventer most useful in test situations such as this. YMMV.
Separation
Some of this answer may raise questions that are not specific to encryption, not specific to sparse bundle disk images, not specific to security. These are potentially complex subjects so please: rather than ask questions in comments beneath this answer, I should probably encourage each question to be asked separately.
-
If you wonder why "… the versions of the remote file are local …", see AFP, Apple versions and security/privacy under apple.stackexchange.com/questions/19299/… Aug 9, 2011 at 10:25
I checked Apple's Developer documentation on the versions feature and it seems to indicate that the previous versions of a document are stored in the same “place” (meaning either the same file, or the same folder) as the current version of the document; but the documentation is scant on details.
There's also the article from AppleInsider titled "Inside Mac OS X 10.7 Lion: Auto Save, File Versions and Time Machine", which says:
Unlike Time Machine, Versions appends all the change snapshots within the local document file, avoiding a file system mess and the need to access backups from a Time Capsule or other external disk just to revert back to previous Versions created in the last several hours.
I have not yet found any more detailed descriptions of how the Versions feature works.
-
I was under the impression that they are stored in
.DocumentRevisions-V100
(and not in the same file as the document)– ThiloJul 26, 2011 at 11:31 -
1@Thilo: yes, you are right. I was misled by how the developer documentation ties the versions feature to the “auto saving in place” feature. As pointed out in the more detailed answers given by others, the older versions of a document are not stored in the same file or folder as the current version. The AppleInsider article is wrong in that regard.– RinzwindJul 26, 2011 at 15:28
Gordon, this is good news for everyone, as well as the software developers for Knox and Espionage (I use both of these apps).
Here's a scenario that users should watch out for though. If you're accessing a file within a mounted encrypted disk image on an external drive, the version files will probably exist on the user's System drive in an unencrypted form. One workaround for this would be to copy the .sparsebundle to the system drive before mounting it.
Another scenario is if the .sparsebundle is on another Snow Leopard Mac on the same network and the image is shared on the network, enabling mounting on a Lion Mac by browsing to it through the Finder. (I do this sometimes.) This would definitely result in any version files being put on the user's System disk in unencrypted form. One workaround for this would be to use screen sharing to control the Snow Leopard Mac, then mount and work in the image on that Mac.
The bottom line is that in Lion, people need to understand more and be more careful than ever when using encrypted disk images if the images are not located on the System drive. I hope the Knox and Espionage developers will warn their customers about these issues.
EDIT: Graham's answer seems to support most of my assumptions.
-
"If you're accessing a file within a mounted encrypted disk image on an external drive, the version files will probably exist on the user's System drive in an unencrypted form". Where do you get that information from? I'd assume it would be placed into
.DocumentRevisions
on the encrypted volume. @Gordon's answer also seems to confirm that.– ThiloJul 27, 2011 at 0:16 -
@Gordon I DK where I got the idea that if the file doesn't reside on the system disk, the version files get stored on the system disk (external disks could have a different file system, don't know if this matters). I thought I read this somewhere, though I can no longer find the source. I assumed that Gordon was only referring to my specific case. Gordon, can you confirm that the versions are stored on the same disk as the actual file, regardless of the formatting etc. of the disk? I know Gordon says, "disk (or disk image)," but he didn't mention this kind of testing.– Phil MJul 28, 2011 at 1:40
-
@Gordon Maybe the 2 specific scenarios mentioned (USB disk & over network on SL Mac) could be tested, I would LOVE to be proved incorrect, I really want this to work.– Phil MJul 28, 2011 at 1:43
-
Good point about external disks in a non-Mac file format. Maybe they don't get versions at all? OTOH, the way this is "hacked" on top of the regular file system could mean that it also works on, say, FAT32.– ThiloJul 28, 2011 at 1:45