When I was playing around with changing modifier keys for OS X I stumbled onto some inconsistencies with permission requirements and abilities for two very similar event types.
The code I used here is modified from http://osxbook.com . You can view the code on github here https://github.com/paddymul/osx_keyboard_play
There are two programs included in the tar ball. getKeyPressCode and insertKeyPressOnModifier. They have a very similar structure. I will start by describing getKeyPressCode
GetKeyPressCode has two functions, main and a call back function. A call is made to CGEventTapCreate , which passes the myCGEventcallBack function in (I’m hazy on my c code, it must somehow pass in a pointer), and event mask flags for the type of event, in this case kCGEventKeyDown or kCGEventKeyUp.
The callback in getKeyPressCode displays the keycode for any character you press, in any application on the system. If you press the = key, it replaces that with ‘f’ .
To run getKeyPressCode, you need to be superuser (sudo) or have Assistive devices enabled. Otherwise the program will fail saying, event tap failed to create. Also notice that when you go to a systemwide password box (such as you would be prompted for in keychain) , no keyUp or keyDown events are fired, even though the program was run with superuser privileges.
The second program is insertKeyPressOnModifier. This program has the same form, the difference is that it catches modifier keys — CGEventFlagsChanged. This program displays the EventFlags for modifier keys (“CAPSLOCK” , “SHIFT”, “CTRL”, “OPTION”, “OPTION/ALT”, “APPLE”) when a modifier key is pressed. When any modifier key is pressed, the program inserts an “=” or “+” depending on whether or not shift was pressed. Again this behaviour takes place in any application on the system.
Now the interesting thing is, you don’t need superuser rights or assistive devices enabled to run insertKeyPressOnModifier. Even more interesting is, inserKeyPressOnModifier still fires events when you are in a system wide password box, it will also insert ‘=’ characters. This seems like a potential security hole.
I filed a bug report for this a year ago, apple hasn’t responded or fixed the hole. This I have observed this behavior on a Mac Book Pro running Tiger and Leopard. I’m not well versed in C, CoreGraphics, OS X internals, or general security measures like this. There could be a very good explanation for the behavior, to me though, it seems like an inconsistency that could be a hole. I haven’t seen the password box behavior mentioned anywhere else.
You can look at the header file for CGEvent on your mac here