Friday, November 11, 2005

Why you should NEVER work with administrative privileges

In the XP world there's no choice but to run with admin privileges -- there's too much software that just won't work unless you do. In the OS X world you can run almost anything as a regular user, and you can install most things that way. (If an app won't run in OS X without admin privileges, don't use it.)

This occult DRM installation story gives yet anohter reason why OS X users should not work as an admin user:
via MacInTouch

I recently purchased Imogen Heap's new CD (Speak for Yourself), an RCA Victor release, but with distribution credited to Sony/BMG. Reading recent reports of a Sony rootkit, I decided to poke around. In addition to the standard volume for AIFF files, there's a smaller extra partition for "enhanced" content. I was surprised to find a "Start.app" Mac application in addition to the expected Windows-related files. Running this app brings up a long legal agreement, clicking Continue prompts you for your username/password (uh-oh!), and then promptly exits. Digging around a bit, I find that Start.app actually installs 2 files: PhoenixNub1.kext and PhoenixNub12.kext.

Personally, I'm not a big fan of anyone installing kernel extensions on my Mac. In Sony's defense, upon closer reading of the EULA, they essentially tell you that they will be installing software. Also, this is apparently not the same technology used in the recent Windows rootkits (made by XCP), but rather a DRM codebase developed by SunnComm, who promotes their Mac-aware DRM technology on their site.
I don't read EULAs. Do you? I didn't think so. If you don't have admin privileges, the OS (for now!) won't allow this kind of install to happen. You may be asked for an admin un/pw -- don't give it!

AppleScript adventures: updating a client iTunes library when tunes are added to a server iTunes library on the same machine (fast user switching)

Aeons ago I wrote Fortran for food during summer break in college. Millennia ago I wrote a utility in C to translate MEDLINE feeds into a form I could import into a database. Now, in my extreme dotage, I have revised an AppleScript that supported updating a client music library one one machine from a master music library on another machine. I did this so both my wife and I could sync our iPods to a shared music library, but keep our own playlists and sync contacts and calendar items correctly.

The revised version differs in seemingly minor ways -- I had to remove 2-3 lines and add 3-4 lines to implement Apple's "new" (introduced in 10.3 but only sort-of-worked in 10.4) support for sending messages to a specific user session. This would have been a trivial task, even for someone like myself who knows nothing about AppleScript, except that there's zero documentation for this new functionality. I got a key tip from a super AppleScript expert -- who gave me the morsel but made it clear I was not to bother him again (I won't give his name out -- he must get these kind of pesky requests hourly and I don't want to add to his pain).

I'll revise the script over time and put it someday in a proper web page, or submit it to the iTunes AppleScript repository. The behavior is pretty ugly however, which suggests whyApple hasn't documented this function. Some background, then the explanation.

It turns out that AppleEvents were all designed with the understanding that there was one instance of an application running on a machine, and that application was available to any authenticated request. Introducing multiple instances of applications seriously messed this up -- in ways subtle and complex. A lot of remote control solutions for iTunes, I now realize, are going to run into this problem. From a few hints I found in my searching, I suspect the behavior of client requests may be unpredictable with multiple AppleEvent targets. It is noteworthy that these events will be processed only when the requester has an administrative username and password for the receiving machine.

So why isn't this documented? A few reasons come to mind:
  • this may still be quite buggy and have very nasty side-effects
  • the user requests need to know the userid (3 digit number) and the process ID for the receiving application. There's no elegant AppleScript friendly way to get these; the only method I know of is 'choose remote application' which brings up a dialog that requires an uber-geek to manage and that is buggy besides. (The Bonjour method doesn't work at all.)
  • it is a very bad security practice that an admin uname and password is required. For all I know these are sent clear text.
So Apple has a partial solution in place, but it is very partial and probably somewhat embarrassing. I suspect there won't be anything better until 10.5. (I think 10.4 will go down in Apple history as very much a 'transitional release'.)

Moderating comments -- and identity management

Gordon's Notes: Comment spam: moderated comments and identity management -- and in this blog too.

Tuesday, November 08, 2005