Do OS X Lion's Versions and Resume features store the cached data for encrypted .sparsebundle images in a secure way?
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?
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.
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.