There’s Something About Input Managers
Tuesday, November 6th, 2007
In brief, an Input Manager is a plugin architecture in Cocoa, originally intended as a way to provide alternative text input methods to NSTextViews. Whenever a Cocoa application launches, it loads all the Input Managers that it finds in the InputManagers folders. Apple provides sample code with their dev tools for making an Input Manager called HexInputServer.
Input Manager plugins are now commonly used as a quick and easy way to make plugins for any Cocoa app. At Ecamm, we use a single simple Input Manager, which loads any of our plugins that you have installed such as DockStar, iGlasses, or Call Recorder into their appropriate applications.
The Mark Twain Effect
We received a lot of emails in the months leading up to Leopard with people asking, “Hey, I heard Input Managers are not going to work in Leopard. 
What are you going to do?” I don’t know where they heard this, because at no point in the many Leopard pre-releases did Apple completely remove Input Manager support. In short, rumors of their death were greatly exaggerated.
We worked our butts off and on October 26th, when the final release of OS X 10.5 rolled off the factory floor, all of our Input Manager-based plugins were ready for Leopard and working quite well.
The Truth About Input Managers
So what’s the deal, what are we doing about it you might ask?
In response to security concerns about InputManagers, Apple decided to place a whole slew of new restrictions on whether or not to allow them to load into apps. These restrictions are very briefly summarized in the 10.5 AppKit Release Notes, and I’ll excerpt that here:
- The valid installation is now restricted to the /Library/InputManagers folder only. Bundles in other locations are silently ignored.
- All the files in the bundle and /Library/InputManagers folder itself must be owned by the root user and admin group. No files inside the bundle can have group or other write permissions.
- Processes running with the root privilege (getuid() == 0 or geteuid() == 0) cannot load any bundle input manager.
- Processes running with the wheel group privilege cannot load any bundle input manager.
- The process must be in the active workspace session at the time of loading the bundles.
- The process must not be tainted by changing user or group id (checked by issetugid()).
- No 64-bit processes can load any bundle input managers.
So what does it all mean?
Let’s go over each restriction in detail:
1. The valid installation is now restricted to the /Library/InputManagers folder only. Bundles in other locations are silently ignored.
On 10.4 and earlier, Input Managers can be installed in the root Library (/Library/InputManagers) or your user Library (/Users/[your user]/Library/InputManagers). If there is an Input Manager with the same name in both places, it completely ignores the one in the root Library and uses the home Library instead.
On 10.5, only Input Managers in the root Library are allowed to load. However, if there’s an Input Manager with the same name in the home Library, it will ignore the one in the root Library and load neither.
Ecamm’s Input Manager has always lived in the root Library so this change did not affect us. Additionally, because people sometimes manually move stuff around, our installer has always zapped any Ecamm Input Manager it finds in the home Library.
This change requires all Input Managers be global (affecting all users). There’s no longer any way for developers to provide the option to install only for the current user. This will be a real pain for unprivileged users, as they will no longer be able to install Input Managers without an admin password. We did have a customer who is an instructor, and uses Call Recorder in a locked-down computer lab environment. We had helped him install Call Recorder in the user Library. This will no longer be possible, at least not possible using Input Managers.
2. All the files in the bundle and /Library/InputManagers folder itself must be owned by the root user and admin group. No files inside the bundle can have group or other write permissions.
In 10.5, every file in an Input Manager plugin’s directory is recursively checked to make sure they meet these ownership and permissions requirements. Additionally, the InputManagers directory itself must meet these same requirements.
In a pinch, the following commands can be used to fix ownership and permissions of the InputManagers folder:
sudo chown -R root:admin /Library/InputManagers
sudo chmod -R go-w /Library/InputManagers
As of their latest versions, the Ecamm installers automatically fix permissions and ownership.
This requirement was the main hurtle to getting Input Managers working on Leopard, but it makes sense to have these requirements if the goal is make this all safer.
3. Processes running with the root privilege (getuid() == 0 or geteuid() == 0) cannot load any bundle input manager.
This one is pretty self explanatory as they’ve given the code they’re using to make the check. If getuid() == 0 , it means you’re logged into your Mac as root. I’m not sure why someone would do this or if it’s even possible. geteuid() == 0 would indicate that the process is running effectively as root (e is for effective). A process is running effectively as root if you run it using sudo, if it is started programmatically using AuthorizationExecuteWithPrivileges, or if it’s running with the setuid bit.
This requirement seems like overkill. The Input Manager has to be owned by root per #2, so why can’t root run its own plugin? Oh well, no big deal. This keeps Input Managers out of sketchy places like loginwindow.
UPDATE: We’ve had a handful of users with all their apps running with geteuid()==0. We don’t yet know why it happens.
4. Processes running with the wheel group privilege cannot load any bundle input manager.
In 10.5, the process’s primary group cannot be wheel (wheel is the name of the root group, gid == 0). Both getgid() and getegid() are checked for 0.
Additionally, the process owner’s supplementary groups are checked for wheel.
This last bit is the one that caught us off guard. We eventually determined that a handful of users who reported problems getting our plugins to load were actually failing this requirement. Their main admin user was a member of the wheel group! This situation is most likely the result of migrating a user account forward from OS X 10.1 (Puma) or earlier, where all admin users were added to the wheel group by default.
If our installer finds that the current user has wheel in its supplemental group list, it simply removes it. Because of the way Cocoa is checking the supplemental groups, a full reboot is required before the change takes effect and Input Managers will load.
5. The process must be in the active workspace session at the time of loading the bundles.
Having an inactive workspace session means that your user is currently switched out via “Fast User Switching”. Fast User Switching allows user B to login without making user A, who was already logged in, have to quit all his programs. It’s then possible to quickly switch back and forth between the two users.
Since Input Managers load when an application starts, I’m not completely sure how an application can start while a user is switched out or what the implications of this are. Anyone have an idea?
6. The process must not be tainted by changing user or group id (checked by issetugid()).
issetugid() makes sure that neither setuid nor setgid have been called. In short, this function makes sure that the process is currently running with the same uid and gid that it was given at birth (execve).
7. No 64-bit processes can load any bundle input managers.
This is an interesting requirement. I can’t think of any good reason for this.
It turns out that checks 2 through 6 are not made when running in 64-bit. Instead, the validation routine simply returns NO.
If they were to allow 64-bit Input Managers, and we actually wanted to have them load into a 64-bit app, we’d simply have to rebuild them with 64-bit architectures.
If you thought things got confusing back when binaries were PowerPC, Intel, or both (Universal), then you’re in for a treat. There’s now up to 4 possible architectures that can be in one mach-o file: PowerPC, Intel, PowerPC 64-bit, and Intel 64-bit. The dynamic loader can’t mix and match architecture types inside one process. So if you want a plugin to load into a 64-bit application, the plugin will have to be built with 64-bit as one of its architectures. To get people around problems like this, Apple has provided a “Open as 32 Bit” checkbox next to the “Open using Rosetta” checkbox. If, for example, Photoshop is made 64-bit capable, then you’ll need to use this new checkbox if you want it to be able to load any of your “old” 32-bit-only plugins.
Another problem plugin developers are going to have on Leopard involves the new Garbage Collection (GC) in Objective-C 2. A process running with GC turned on cannot load non-GC plugins. It’s a little bit more complicated than this, but I won’t go into details.
A strange turn of events
As a result of check #3, Input Managers no longer load into certain processes where you’d probably agree you don’t want Input Managers.
For example, on 10.4 and earlier, Input Managers load into loginwindow. This is no longer the case on 10.5.
However, in a very interesting turn of events, Input Managers now load into the Finder. Go figure. 
Following a continuing trend of adding new things without telling anyone, the recent 
QTKit Capture looks to be a total ground-up replacement of the Sequence Grabber. The Sequence Grabber is a very ancient part of QuickTime, designed long ago as the way to capture streaming audio/video. It doesn’t appear to be going away, but QTKit Capture doesn’t use it internally except for reverse compatibility* with old vdig drivers. Where the Sequence Grabber uses QuickDraw, QTKit Capture makes heavy use of Core Video and OpenGL. Also, the top layer is Objective-C so it can be integrated easily into a Cocoa app.
CoreMediaIOServicesPrivate’s framework Resources folder contains a number of plugin modules. There’s one for AVC (DV cams), IIDC (external iSight), and VDC (the built-in iSight). In a nutshell, CoreMedia appears to implement a Device Abstraction Layer (A way to allow access to all video devices without having to know the details of the device.)
You can see we used an NSBrowser for the file browser. If you’ve ever tried to use one of these you’d know that they’re not very useful out of the box. Drag and drop has to be implemented manually, and the updating of cell data is very flaky, requiring many work-arounds. Also, they don’t do many of the things that you’d come to expect from the Finder’s column view mode.
The iApps like iChat and Photo Booth only request a 640×480 or smaller image from the iSight. Therefore it can be troublesome to find a way to test the full capabilities of the new 1.3 MP iSight. That’s why we wrote our own little test program.