Volume Number: 23 (2007)
Issue Number: 08
Column Tag: Mac In The Shell
by Edward Marczak
With the advent of OS X, most Mac developers were introduced to the concept of bundles. More properly divided into bundles or packages, they both refer to a file-system directory that groups related resources together. This is true for frameworks (bundles: transparent structures that a user can easily access the contents of), applications (a package: an opaque bundle that requires work on the part of the user to open; contents are not easily modified), kernel extensions (another package), certain document types (check out Pages and Keynote, for example) and others. A bundle follows a very specific file layout, meaning, you'll know where to go find the goods. Follow along for a tour, and let's uncover some hidden apps.
Those of us working with the Macintosh for a long enough period of time remember ResEdit, the resource format of OS 9, and all of the types we could store in the resource fork of a file. While OS X recognizes and respects the traditional dual-fork file, its format is deprecated, being replaced by the bundle. The purpose of a bundle is to keep the resources of an application, plug-in or framework in one place. This makes the contents easy to locate and easy to move without damage. What can go into a bundle? Well, technically anything, but you'll typically find the following types of data stored there:
Sounds
Images
Private libraries
String resources
Executable code
Naturally, it's the latter that interests us in this article.
Typically, to launch an application from a shell, you'd use the open command, like so:
open /Applications/TextEdit.app
This will always run the application in the context of the user, even if launched from a root shell, as shown in figure 1:
Figure 1 – TextEdit running as a standard user.
Of course, there are times where you may want (or need) an app to be running with some elevated privileges. How can we achieve this? Time to go digging!
As mentioned, a bundle conforms to a specific layout. Listing 1 shows this hierarchy using TextEdit as an example.
Listing 1 – TextEdit.app as bundle
TextEdit.app/ Contents/ Info.plist MacOS/ TextEdit PkgInfo Resources/ DocumentWindows.nib ... zh_TW.lproj version.plist
The first item in all modern application bundles is the Contents folder. It is under this folder that all other objects reside. Within the Contents folder, you'll find an Info.plist file that tells the Finder many things about this bundle, including the bundle name, version, signature, applicable data types and more. You'll also find a Resources subdirectory, typically containing the images, sounds, movies and other resources used by the application. The application's executable itself resides in the MacOS subdirectory. If you are to look in there now, you'll find the TextEdit application. You can launch the application directly from here.
Gain a root shell using your preferred method, and launch the TextEdit application directly – not using open. Like this:
# /Applications/Textedit.app/Contents/MacOS/TextEdit
Now let's have a look in Activity Monitor, and you'll see that it's running with root privileges.
Figure 2 – TextEdit running with root privileges
Of course, the real point of this is not so much running with root, but the fact that you can access these binaries from the shell in some meaningful way.
Well, launching TextEdit is nice and all, but, not extremely practical. I'd like to continue with two very real-world examples that have made a difference in my daily work. While every GUI application will have its "true" binary buried in the application package, it may also have any number of helper-apps or other binaries that the app relies on. These are typically found in the Resources directory of the bundle. The easiest way to find executables in a bundle would be, in a shell, to change into the bundle directory and use this handy find command:
find . -type f -perm -100
This will allow you to quickly scour Application and Framework bundles. For instance:
$ cd /System/Library/CoreServices/RemoteManagement/ARDAgent.app/ $ find . -type f -perm -100 ./Contents/MacOS/ARDAgent ./Contents/Resources/ARDPref.prefPane/Contents/MacOS/ARDPref ./Contents/Resources/ARDPref.prefPane/Contents/Resources/prefwritesettings ./Contents/Resources/kickstart ./Contents/Resources/RemoteDesktopAgent ./Contents/Support/ARDForcedViewer.app/Contents/MacOS/ARDForcedViewer ./Contents/Support/ARDHelper ./Contents/Support/build_hd_index ./Contents/Support/networksetup-panther ./Contents/Support/networksetup-tiger ./Contents/Support/Remote Desktop Message.app/Contents/MacOS/Remote Desktop Message ./Contents/Support/sysinfocachegen ./Contents/Support/systemsetup-panther ./Contents/Support/systemsetup-tiger
That's some wonderfully revealing information!
The first really useful binary comes from the MacFUSE project. If you've installed MacFUSE core and the pre-compiled ssh filesystem, run our find command in the sshfs.app bundle. (If you haven't installed this, you should! It's an incredible resource. Find out more at http://code.google.com/p/macfuse/). Out of all the things we're returned, this turns out to be what we're looking for:
./Contents/Resources/sshfs-static
The sshfs-static binary lets us mount ssh file systems via a shell command rather than using the GUI app to do so. What's this good for? Automation, of course! In fact, you can use it to mount a remote ssh file system proactively, or in response to just about any event.
The easy thing to imagine is a nightly file copy. Mount the file system first, then, use ditto, rsync, or your preferred file moving method, and then unmount (using the standard umount command as, under OS X, there is no FUSE-specific unmounting needed). Better yet, though, think about a launchd job that watches a particular folder and perhaps copies files to a remote location as they show up in a source folder. Hmmmmmmm. So, how can we use this thing?
One way to make your life easier would be to symlink the sshfs-static binary to some appropriate location in your path. I'm going to run it straight from the application package, however, so for these examples, you'll need to change directly into the sshfs.app/Contents/Resources directory.
First, create a mount point for the file system. Then run the sshfs-static app and supply the following parameters:
user@hostname:/path/to/directory mountpoint -oreconnect,volname=name appearing in the Finder
The "reconnect" option, supplied with the -o switch isn't necessary, but does make things smoother if there's a network interruption and you're disconnected.
Since this all rides on top of ssh, ssh keys are respected. So, if you've generated some password-less keys, just like ssh, you won't be prompted for a password. Let's see this in action. First, I created /tmp/ssh as a mount point. Then, I used sshfs-static to mount a remote system:
$ ./sshfs-static marczak@www.example.com:/ /tmp/ssh -oreconnect,volname=wsweb kextload: /System/Library/Filesystems/fusefs.fs/Support/fusefs.kext loaded successfully
...and let's take a look at it with mount:
$ mount /dev/disk0s2 on / (local, journaled) [snip] sshfs#marczak@www.example.com:/ on /private/tmp/ssh (nodev, nosuid, synchronous, mounted by marczak)
Figure 3 shows the result of this in my Finder sidebar.
Figure 3: An ssh file system ("wsweb") as seen in the Finder
Very, very, very cool.
While 'black-hat' tools such as nmap sometimes get a bad rap, the fact is that tools like this are also perfect for system administrators when troubleshooting network issues. "Can I reach that port?" and "Is the target port open and responding?" are two of the most frequently asked questions when troubleshooting issues and planning network configurations. While I load nmap on my machine, I often find myself remotely accessing someone in need of assistance because his or her e-mail app "won't work" (residential ISPs typically block port 25) or iChat won't work in some manner (misconfigured/tightly restricted firewalls sometimes will block AIM or Google Talk/Jabber). It would, of course, be a chore and not very friendly to go load nmap and other tools onto someone else's system at that time. Is there a substitute built in to OS X?
Network Utility.app to the rescue! Huh?!? You expected a shell utility, right? Well, there's one hidden in the very graphical Network Utility.app that's found in your Utilities folder. Let's run our find command:
$ cd /Applications/Utilities/Network\ Utility.app/ $ find . -type f -perm -100 ./Contents/MacOS/Network Utility ./Contents/Resources/stroke
Of course, we knew about MacOS/Network Utility, but Resources/stroke looks interesting! Nicely enough, the developer that wrote stroke was also kind enough to include a usage statement if you run it without parameters:
$ ./stroke
2007-06-22 08:41:13.136 stroke[2113] stroke address startPort endPort
Let's see it in action:
./stroke 192.168.100.12 20 500
Port Scanning host: 192.168.100.12
Open TCP Port: 22 pcanywherestat
Open TCP Port: 25
Open TCP Port: 53
Open TCP Port: 80
Open TCP Port: 106
Open TCP Port: 110
Open TCP Port: 119
Open TCP Port: 139
Open TCP Port: 143
Open TCP Port: 311
Open TCP Port: 389
Open TCP Port: 427
Open TCP Port: 443
Open TCP Port: 445
Open TCP Port: 465
Well, that's another useful tool that was buried, waiting for discovery. (Bonus points if you recognize the OS that I scanned).
The examples given here really only scratch the surface. There are plenty more hidden gems to be discovered. Take a look in your favorite applications. Dig in and see what you find! You will need to go hunt these utilities and helpers down yourself as they won't be in your shell's path.
Media of the month: Lost Season 1. OK, call me cheesy, but I really dig the show and am surprised at how many people have never given it a chance. Well, Summer is here and it's a great time to rent the DVDs and watch them at your own pace. If you're in the Southern Hemisphere, it's Winter....and what a great time to get under a blanket on the couch, sip some tea and watch a show...especially one that takes place on a tropical island! Enjoy.
WWDC 2007 has come and gone now, and got to reinforce the new concepts in Leopard. I hope everyone who went enjoyed the show, and will start practicing with the new tools and APIs...and have new tools, utilities and techniques ready for when Leopard ships. I've been plumbing the depths of the beta from the show, and have been pleasantly surprised.
Until next month, keep exploring!
Apple, Inc. "Bundle Programming Guide"
Ed Marczak gets dressed in the morning, drinks tea and enjoys breathing. All of this comes in handy in his role as Executive Editor of MacTech Magazine, or when running his consulting company Radiotope. They're also good features when around children. Why? http://www.radiotope.com/writing
