SMJobSubmit

By Peter N Lewis on Monday, August 6, 2012

Apple deprecated AuthorizationExecuteWithPrivileges but was not very clear about how to replace it - turns out it is easy enough to do using SBJobSubmit.

Nathan de Vries wrote a great article, Modern privileged helper tools using SMJobBless + XPC about using XPC with SMJobBless to install and communicate a privileged helper.

But all I wanted to do was execute my simple little script to handle the update for Keyboard Maestro in the case where the user did not have sufficient privileges to do it directly. It turns out that it is relatively easy to replace AuthorizationExecuteWithPrivileges with SMJobSubmit.

First, a digression on the difference between SMJobBless and SMJobSubmit, because it took me a while to figure it out.

SMJobBless installs (permanently) a launchd LaunchDaemon. You must ensure that your daemon is signed appropriately and add a bunch of other plist entries and such, all covered Apple's SMJobBless sample code. The system will ensure that only your signed application can add/remove the tool. Once the user has authenticated, the helper is installed and will permanently run (on demand) as a privileged tool. Nathan's sample code shows how to communicate with it, but nothing that I can see prevents anyone else from communicating with it, so there is still a huge security hole requiring you to provide some level of authentication on your communication stream.

SMJobSubmit on the other hand install temporarily a launchd LaunchDaemon. You provide the LaunchDaemon dictionary with a reference to your executable. The user must authenticate each time you do this. You can use the RunAtLoad key in the dictionary to have your tool launch immediately, and you can build your script at runtime to include parameters, so you may well be able to avoid communication altogether.

In both cases, you must use SMJobRemove to remove any previous version, even in the case of SMJobSubmit, since the job will stay in launchd's system (presumably until reboot) and will not be replaced. Note that while the code below passes false to the SMJobRemove wait parameter, if you plan on doing another SMJobBless or SMJobSubmit in the near future, you should set the flag to true otherwise the system may occasionally report errors or code signing issues (thanks to Bryan Christianson for this tip).

Here is some example code.

NSString* myLabel = @"com.mydomain.myhelper";

AuthorizationItem authItem = { kSMRightBlessPrivilegedHelper, 0, NULL, 0 };
AuthorizationRights authRights = { 1, &authItem };
AuthorizationFlags flags = kAuthorizationFlagInteractionAllowed | kAuthorizationFlagPreAuthorize | kAuthorizationFlagExtendRights;

AuthorizationRef auth;
if( AuthorizationCreate( &authRights, kAuthorizationEmptyEnvironment, flags, &auth ) == errAuthorizationSuccess ) {
    (void) SMJobRemove( kSMDomainSystemLaunchd, (CFStringRef)myLabel, auth, false, NULL );

    NSMutableDictionary *plist = [NSMutableDictionary dictionary];
    [plist setObject:myLabel forKey:@"Label"];
    [plist setObject:[NSNumber numberWithBool:YES] forKey:@"RunAtLoad"];
    [plist setObject:executablePath forKey:@"Program"];
    CFErrorRef error;
    if ( SMJobSubmit( kSMDomainSystemLaunchd, (CFDictionaryRef)plist, auth, &error) ) {
        // Script is running
    } else {
        NSLog( @"Authenticated install submit failed with error %@", error );
    }
    if ( error ) {
        CFRelease( error );
    }

    (void) SMJobRemove( kSMDomainSystemLaunchd, (CFStringRef)myLabel, auth, false, NULL );
    AuthorizationFree( auth, 0 );
}

Updated Monday, August 6, 2012 at 12:00 AM. Permalink. 6 Comments.