:space
:vision
do not step out
:wire
twitter.com/mikeysan
no soup for you
03/Jul/2005 | 08:48

AppleScript Studio vs DirectoryService: Round One

This morning, my system log has a story to tell:

Jul 3 07:34:06 mikeys-computer authexec: executing /bin/sh Jul 3 07:34:10 mikeys-computer authexec: executing /bin/sh Jul 3 07:34:12 mikeys-computer authexec: executing /bin/sh Jul 3 07:34:14 mikeys-computer authexec: executing /bin/sh Jul 3 07:34:16 mikeys-computer authexec: executing /bin/sh Jul 3 07:34:18 mikeys-computer authexec: executing /bin/sh Jul 3 07:34:22 mikeys-computer DirectoryService[41]: Failed Authentication return is being delayed due to over five recent auth failures for username: mikey.

I've been developing a big AppleScript Studio application for the past week, and I'm getting close to an initial release. The script passes several commands to the shell via do shell script while obtaining privilege by utilizing with administrator privileges. Think of it as sudo for AppleScript:

do shell script "/usr/bin/true" with administrator privileges

This is analagous to sudo /usr/bin/true, except that you get a nice, standard Mac OS X authorization request dialog to go along with it.

Now, In Mac OS X 10.4, with administrator privileges doesn't use sudo, it uses SecurityServer. Specifically, it calls AuthorizationExecuteWithPrivileges() to gain privilege for executing commands with /bin/sh. It would appear as though SecurityServer isn't pissed off (as I find nothing but successful authorizations by SecurityServer in secure.log), but DirectoryService is definitely throwing a hissy fit. The question is, though, just what's going on here?

(If anyone has corrections to the above, please hit me in the comments.)

At any rate.

The app, which I'm going to release despite the problem I'm about to describe, makes extensive use of this authorization feature [of AppleScript], partially because the nature of the app calls for (CALLS FOR, GET IT, IT'S A PUN) several of its authorization-hungry functions to be performed multiple times. Where things get ugly is after several successful authorizations, when the system throws an error (Failed Authentication) and begins delaying return. This means that after a few successful commands, the system starts increasing the delay between executed privileged commands. What's throwing me for a loop (MORE PROGRAMMING HUMOUR) is that nothing's actually being denied; I'm still successfully executing the commands that are being issued via do shell script with administrator privileges.

Here's a test program (Xcode 2.1 required to build), source code included.

So is this a bug in Tiger? If so, whose fault is it? AppleScript? SecurityServer? DirectoryService? If it's not a bug in Mac OS X, but a problem with how the script is written, how can it be solved?

Anyone willing to help dig into this one?

Update: Plot Thickens

I've continued to experiment with this issue, and I've found that this form of the command does not trigger it [the issue]:

do shell script "true" user name theUser password thePass with administrator privileges

Unfortunately, this method requires that you get and set the user name and password without the standard Mac OS X authentication dialog. I find this unacceptable from a security standpoint, since this would require declaring the password—in plain text or weakly obfuscated—as a global or a property in the script. You could pass it like(this) from handler to handler, but I'm still weary of this method.

Before I digress terribly, /var/log/asl.log tells a slightly more verbose story than system.log does:

[Time 2005.07.03 20:01:24 UTC] [Facility auth] [Sender authexec] [PID -1] [Message executing /bin/sh] [Level 5] [UID -2] [GID -2] [Host mikeys-computer] [Time 2005.07.03 20:01:26 UTC] [Facility daemon] [Sender DirectoryService] [PID 41] [Message Failed Authentication return is being delayed due to over five recent auth failures for username: mikey.] [Level 1] [UID -2] [GID -2] [Host mikeys-computer]

At least that second line isn't showing up anymore, even if that means I can't use standard system dialogs. For now.

2 Comments:

Well, if you wanted to avoid the auth dialog in a more secure way, you could always use keychain scripting, although that has a minor issue as of 10.4.1

posted by John C. Welch on July 05, 2005 at 08:29

It seems that "with administrator privileges" works better now in Mac OS X 10.4.2, especially for lauching gtk apps which were complaining when being launched using setuid.

posted by Pierre on July 14, 2005 at 05:50