Security "leak" in OS X Drop Box folders: the explanation

What the privileges settings really mean If you check the Show Info window, you will see that the Drop Box folder is set for Write Only privileges for Group and Everyone. You might think this means what it says (for example, that it means you can't read any files in that folder). But you would be wrong.

The actual Drop Box UNIX permissions settings for Everyone are <-wx>. This can be viewed from Terminal (as we describe in a moment). This means that Everyone has write (w) and execute (x) permission for the folder. In UNIX, the x (execute) bit must be set for a folder for r (read) and w (write) to have any effect at all. It has nothing to do with "execute." In fact, when used with folders/directories, it is more often referred to as the "search" bit than the "execute" bit.

Thus, with <-wx> permission for Everyone for a folder, a user is able to add files to the folder and also remove files from the folder. In fact, the lack of read access only means that you are unable to view/read the contents of the folder/ directory. It does not mean that you cannot read individual files within the directory. Actually, as we have seen, you can read them. That is, even if the folder does not have read permission set, you can still read and modify files inside it (accessed via a Sherlock search), if the folder has write permission set (and if you have read access to the file itself!). Files in such a folder are thus insecure.

Set the sticky bit Is there a better way? Yes. To further restrict access to the contents of a folder you must set the sticky bit for the folder. If the sticky bit is set, anyone can add files but only the owner of the folder or of the file can remove a given file. This does not affect read access however (you can still read the file or copy it).

To set the sticky bit for your Drop Box, you need to add a fourth digit ("1") preceding the standard trio of digits used in the chmod command (this is the command that sets permissions in UNIX). In this case, do the following:

Alternatively, you can use a utility such as XRay. With XRay, go to the Permissions pane, click the triangle to reveal the additional options. "Sticky bit" should be listed as an option that can be enabled. Do so.

The result Using either method of enabling the sticky bit, other users will now be unable to remove files from your Drop Box folder. Further:

If another user now drags the file from the Sherlock window to the Desktop, it copies the file instead of removing it. You can still open the file from the Drop Box or via the Desktop copy, so the contents is available for reading.

If you try to Save the document, you will again get the message that says: "Couldn't Save. Attempt to overwrite?" If you click to Overwrite, you will again get a message that simply says "Couldn't Save." However, the original file now remains intact. A temporary rtf file with the supposedly unsaved changes will also be created, but at least the original file is not lost.

Overall, it looks like setting the sticky bit for the Drop Box would be a good idea. It doesn't keep users from reading files here. But it does keep them from modifying them. It also points out how the Show Info phrase "Write Only" suggests a very different meaning to non-UNIX savvy users than it really means. It is also different from what it means in Mac OS 9, where all access to files in a Drop Box are indeed blocked.

OS X vs. UNIX Given all this, what now seems odd is that TextEdit refused to save the modified file to begin with. Tony Ewing notes: "The strangely named file is the temporary file created by TextEdit when it is attempting to save. TextEdit does not correctly clean up its temporary file if it fails to rename the file." Beyond that, we are not sure why TextEdit "partially" refused to save a file that should have been saveable. Perhaps, the Finder attempts to do a better job of enforcing what "Write Only" means than does the UNIX subsystem.

Also note, for example, if we set the privileges for a TextEdit file in Bob's Public folder (with File Sharing enabled) to "None," the file would not open in TextEdit (when logged in as Ted) although it would open if the file's privileges were "Read only." This is consistent with how UNIX works.