Posts tagged Mac

I tried [Dropbox]. The promise of working cross device file sync sounded really intriguing, but the final straw was [Elements]. Elements is a great app. I purchased, downloaded, and launched it. I signed up for Dropbox right there, then downloaded Dropbox onto both my laptop and my desktop.

Installation was drag-and-drop. From what I’ve heard, the sync works wonderfully. However, when I first launched the app on my laptop, it asked for my administrative user name and associated password. That’s a bit odd for any app, especially one which does not modify the system in any way, so I investigated a little. Dropbox installs three pieces into one’s system when it first runs.

The first one is the app itself, but when launched it marks two files within the app bundle as set-user-id-root (suid). This is extremely strange and extremely dangerous, from both a stability and a security perspective.

The second is a Contextual Menu Item, which is a plugin which adds an item to the right-click menu. However, in addition to the extra feature added to the context menu, this plugin also injects an additional “plugin” when it loads. This is extremely strange and extremely dangerous, from both a stability and a security perspective. (This plugin was for finder.)

Third, it installs a file named “.dropbox” (w/o quotes) in one’s home folder. The placement of this file is strange (the appropriate places would be ~/Library/Application Support/Dropbox and ~/Library/Caches/Drbox), but not at all dangerous.

Some of these mistakes come from Dropbox’s recent addition of Mac support. That is, they just don’t know any better. On windows, significant stability damage through the use of novel and unexpected code injection is the norm. A carefully designed “plugin” would put no more strain on the system than what comes on the system from the original manufacturer. (I’m not saying that windows is more stable with “plugins,” but that nobody would notice the instability introduced by these “plugins.”) On Linux, suid binaries are entirely normal. In fact, significant parts of the user land live entirely in root space, e.g. the X window system itself. There, the security implications are dealt with through over engineering and careful disclosure, while the stability implications are expected to be dealt with by the system administrator (read: end user).

On Mac, however, stability and security are two of the platform’s primary draws. Those two reasons are exactly why I, myself, use a Mac. Furthermore, as a software developer, I can clearly see solutions to the problems that Dropbox appears to have been attempting to solve. For example, the contextual menu could be provided by a “service”, thereby bypassing the need for that plugin. The code-injected Finder “plugin” could be scrapped entirely and replaced with careful use of custom folder icons, supported by the very same folder-change-monitoring system used to watch for actual content changes. Actual content changes could be provided by the system that Apple built into the platform for that very purpose: FSEvents. This is part of the system that Spotlight and Time Machine use.

I uninstalled Dropbox shortly after my investigation. Perhaps I’ll try it again once they’ve had a change to fix up their Mac support.

Warning

IMPORTANT: DOING THIS TOO OFTEN WILL SIGNIFICANTLY REDUCE PERFORMANCE. Furthermore, the equivalent happens automatically. THIS IS A TOY ONLY.

Fun With Debugging Tools

Do you like it when Activity Monitor reports large amounts of free memory, regardless of actual performance? Try this: open Terminal and just type “purge” (without quotes).

OMG WTF BBQ

Pretty neat, eh?

Details

The purge(8) utility is a debugging tool which interacts with the Unified Disk Cache. Basically, Mac OS X (and all modern OSes) keeps recently (or frequently) used files in RAM, since it is fairly likely that they’ll be used again very shortly. This does, in fact, happen more often than not.

Most files are tiny and read once and “never” again. (We’re talking about seconds here, so re-opening the same file tomorrow or after lunch is like talking about how your house will look in the year 2256. Its just as good to say “never.”) These files drop out of the disk cache quickly enough, since they’re closed (programatically) as soon as they’re opened. Other files are enormous (many megabytes) and are rarely merely loaded and closed. Instead, these files are frequently read partially, again and again, and often modified in-place. Often, these files aren’t ever read start-to-finish, and certainly aren’t closed once read. Examples include databases, any sort of for-editing media (audio, video, images, animation, &c.), and even not-for-editing consumer-targetted media files (like a 1.4GB movie downloaded from iTunes).

Most applications interact with files in ways that lets Mac OS X know which category they fall into: open and “discard”, or frequent access. Even when they don’t, Mac OS X is fairly good at guessing.

When an application behaves as though it is clearly within the frequent access category (i.e., working with enormous files that simply couldn’t fit into RAM at all), an app may nevertheless explicitly tell the system that it is really in the other category. Creating a new ZIP or TAR archive, or exporting from source material to ProRes, are some examples of this sort of exception.

The problem comes in when an application is working with those aforementioned enormous files, but neglects to tell the system that it really should be in the other category. The purge(8) utility exists so that a developer or system administrator can debug this situation.

Purge(8)

The purge(8) utility merely empties the aforementioned disk cache. That’s all.

Just like all caches, the purpose of the cache is to increase performance. And, just like all caches, emptying the cache is usually pointless and generally unnecessary. Just like all caches, it will clean itself over time. Unlike the cache in a web browser, though, “over time” is minutes not days or weeks. However, just like the cache in a web browser, it is extremely unlikely that you will get any performance improvement by manually emptying it.

In rare situations, however, a developer or system administrator may know specifically of a situation where the built-in heuristics will guess wrong, or at least not guess quickly enough.

FileVault was introduced in Mac OS X v10.3, if I recall correctly. Basically, it replaces one’s home folder with a disk image, which is mounted during login and unmounted at log out. The idea is that the disk image is encrypted, and so therefore your home is encrypted. At first, this sounds like a fantastic idea: real data security. However, there are often misunderstandings about what this does and how it works.

A fundamental requirement of any encryption system is that it fails closed. What does “fails closed” mean? When something fails, what happens? If a door lock fails, then its either stuck open or stuck closed. If stuck open, then you can’t lock your door. If it fails closed, then you can’t unlock your door. The goal of all encryption systems is to fail closed. If anything is tampered with, then the contents are inaccessible. Only a working lock (disk image) with a working key (password) can be unlocked. If it ever failed open, then anyone could just come along, smash the lock with a hammer, and walk in.

So, you’ve probably already realised why this is a problem for users of a consumer operating system on a consumer computer. If you drop your laptop, then your hard drive is damaged, then your lock is damaged, then it doesn’t matter if you still have your key. Worse, what if you lose your key? Worse, what if your lock breaks by itself during one of the myriad occasions when a consumer operating system or a consumer computer fails by itself? (I’m not talking hardware failure, but simple application crashes, kernel panics, unexpected sudden power loss, &c.)

The result is that, unless you have some reason to be significantly concerned about data theft, your concern for data loss ought to outweigh all possible motivation for turning FileVault on.

Sadly, we are talking about consumers here. These people don’t backup. Their fear of windows viruses produces an unreasonable desire to turn on anything labelled “security”.

Therefore, FileVault is often a cause of complete, catastrophic data loss.

Well, if you do backups, for example using Time Machine (properly), and you don’t forget your password, and you understand that encryption systems are designed to fail closed, then there aren’t really any down sides, even though FileVault is admittedly often a cause of catastrophic data loss.

I turned on FileVault because I don’t want anyone to get my data if they steal my computer. I don’t want my login details (even though the passwords are encrypted) recovered from my keychain. I don’t want my financial details recovered. I don’t want my personal files recovered (not just pr0n, but also personal e-mails &c.). I recognise that I must now log out in order for my backups to happen. I recognise that I must be more careful about where I save enormous files (such as my iMovie Events folder or disk images of any software I purchase). I recognise that even if I’m extremely careful, my home might be corrupted anyway and I’ll have to restore from backup.

OK. It’s worth it. I don’t want anyone to be able to report what brand of pr0n I like. Not just because of the embarrassment it may cause, but because of the misguided social constructs which govern any sort of public behaviour and which have been enshrined in the ethics requirements of my profession. (I have a whole other essay on why “ethics” requirements are anything but.)

Postscript: Of course, Apple has taken steps to ensure that FileVault is less troublesome. Starting in Mac OS X v10.5, Apple introduced a type of disk image called a “sparse bundle” which breaks the disk image itself into hundreds of tiny files so that the chance of file corruption causing complete data loss is much lower. The sparse bundle format also serves to separate some of the metadata from the file data to improve fault tolerance.