Time Machine backups to a drive on another Mac over the network

I've got a huge external drive on my desktop Mac which I use for a Time Machine backup. However, my MacBook has gone un-backed up for a long time. I had heard over the years that you could hack your way to a network Time Machine backup, but never bothered trying (I try to avoid hacks because they usually blow up in my face and takes a ton of time to fix). However, now that I'm using Aperture heavily on my laptop, I don't want to go without a backup of all of my pics.

Turns out, it's very, very easy to set up an external drive on one Mac as a Time Machine volume over the network.

1. Share the external hard drive. To do this, do a Get Info on the external drive and click the Shared Folder checkbox.
2. Open up System Preferences > Sharing.
1. Make sure File Sharing is enabled.
2. You should see the external hard drive listed in the Shared Folders column. Click it.
3. Click the + icon in the Users column and add the user you connect with from the networked computer.
4. Set up Read & Write access for that user.
5. Ideally you should remove/lower privileges for other users here. In my case the shared external drive had all kinds of unreasonable default permissions for Unknown User, Guest, and Everyone.
3. On the networked machine, go to the terminal and enter:

   defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1

4. Use the Finder to connect to the machine hosting the external drive with the user you configured in step #3 above.
5. Open System Preferences > Time Machine.
6. Click Select Disk.
7. You should see the external drive listed, pick it.
8. Profit!

So next you're probably wondering, dang this initial backup is going to take forever. Well, there's a trick for that, too. Apple File Sharing works over a local non-routed network (ie Bonjour). So just hook up your two computers with an ethernet cable, and disable WiFi on the machine that doesn't have the external drive attached. You should still be able to see the shared external drive in the Finder, only now it's running on Gigabit Ethernet (or the fastest your two machines can manage with each other). This is a great way to do the initial backup, and subsequent backups will be much smaller and not as big of a deal.

Enjoy!

Mouse support for Terminal.app: scrolling, vi/vim, and more!

Goofing around on the internet today just got real. I was reading about ncurses and noticed that the API supports mouse events. So wait, if terminals can support mouse events, then why doesn't vim in Terminal.app work like gVim and support mouse scrolling, clicking, and selection? It can, and it's AMAZING!

Someone wrote a SIMBL plugin called MouseTerm that passes through all mouse events to the terminal. After that, all you have to do is enable mouse support in vim, and Boom goes the Dynamite!

Steps:
1. Install SIMBL
2. Install MouseTerm
3. Edit your .vimrc:

" mouse support
if has("mouse")
    set mouse=a
    set ttymouse=xterm2
endif

4. That's it! Now you can use the mouse for clicking, selection, and scrolling!

One thing I did notice is that you can no longer copy text to the Mac clipboard from Vim in this mode. It's easy to toggle mouse event passing with Cmd-Shift-M (or menu item Shell > Send Mouse Events).

I used the ttymouse=xterm2 since it is the one recommended for use with gnu screen. ttymouse=xterm didn't behave properly for me when vim was used inside of screen.

Thanks to Ayaz for this article on "Using mouse inside Vim on Terminal.app" which got me pointed in the right direction.

Security Caveats with S3: it's easy to grant dangerous permissions with Bucket and User policies.

We've been exploring ways to use S3, and one of the ideas was to dynamically create buckets on-the-fly for individual customers to store and manage their objects.

Since we take security very seriously, we took a deep-dive into S3's permissions model to be sure that we could eliminate the risk of data loss due to application logic error and/or security breach of the web server.

As with any security setup, partitioning of access rights is key to risk mitigation. Thus we created an unprivileged webapp user that could not permanently delete S3 objects. Of course, we were trying to create buckets on-the-fly, so this same user would need the ability to create buckets and set bucket policies.

As it turns out, it's not possible to do this securely. This was a big shock to me, since what it means in practice is that UserA can grant rights to UserB even if UserA doesn't have those rights himself.

Steps:
1. Bucket Owner grants *only* PutBucketPolicy to UserA
2. UserA grants DeleteObject / DeleteObjectVersion to UserB.
3. UserB can now permanently delete every object in the bucket.

Even more shocking, this is also true if you've gone the extra step of enabling MFA-delete on the bucket. This means that you need an MFA device to successfully permanently delete objects. However, you don't have to have the MFA device originally used to enable MFA-delete. In the above scenario, even with MFA-delete enabled, UserB can buy his own MFA device, attach it to his account, and permanently delete any object in the bucket.

Furthermore, there is no place to attach deny rules that could not be similarly overturned, since the only place to attach such a rule is via a Bucket Policy, and of course that deny can be easily overwritten by the webapp user with the PutBucketPolicy permissions.

The bottom line is that giving PutBucketPolicy to a user is equivalent to giving them root access to the bucket. They can do anything. Thus, the AWS/S3 permission model is not currently suitable if you'd like your web application to be able to create and configure buckets on-the-fly.

I do not have enough of a security background to know if this is considered bad security architecture or just a normal caveat of complex permissions models, but I was personally very concerned that a user could grant permission he didn't have himself.

All of this has been confirmed through multiple experiments as well as with AWS Support. It is true. So be careful!