Just updated to 10.9.2 and it seems so far that running do shell script with admin privileges no longer works. I feared something like this was coming. Well, actually it does run the process ( in this case rsync ) but it throws a lot of errors in console and freezes up the UI. Without admin privileges it works fine still. In a regular Applescript it seems to work ok (without a UI )and shows no errors. Even if I code sign my app it still won’t work. They have made some heavy duty gatekeeper improvements it seems.
Before if your app wasn’t sandboxed they allowed you to run a subprocess as root but had deprecated AuthorizationExecuteWithPrivileges()
I assume do shell script with admin privileges is an applescript wrapper for AuthorizationExecuteWithPrivileges() and wondered if they might pull the plug on that too. Some people were using NSApplescript inside their cocoa code to get around the very difficult authorization requirements.
Anyone else have any experience with this?
This is the error I am seeing…
2/26/14 9:18:59.116 PM Finder: AppleEvents/sandbox: Returning errAEPrivilegeError/-10004 and denying dispatch of event syso/rond from process 'backupList+'/0x0-0x140140, pid=2003, because it is not entitled to send an AppleEvent to this process.
I wish! No tell block in sight. Just plain do shell script “blah” with administrator privileges. Worked perfectly before on 10.9.1 and frozen on 10.9.2. Others report same thing so I know it isn’t just my machine having update attack.
Ok so I made a test app, very simple with a window, progress bar, button. Simple script which launches rsync via do shell script.
set rsyncString to "'/rsync' -aHAXN --fileflags --progress '/folderx' '/Volumes/Backup/foldery' &>/Users/me/Library/Logs/rsync.log & echo $!"
set pid to do shell script rsyncString with administrator privileges
log "pid = "& pid
set rsyncTimer to NSTimer's scheduledTimerWithTimeInterval_target_selector_userInfo_repeats_(1, me, "loopCheck:", missing value, true)
The loop check handler checks output and updates progress window with paths.
When asking for privileges the UI freezes and script doesn’t continue until rsync dies and then it finishes up. Spinning beach ball happens. Without privileges it sails along fine as before under OS 10.9.1. There are no errors from finder this time ( never did see any reference in my big script to finder!) but the following do occur:
2/27/14 8:00:33.975 PM launchservicesd: Application App:"rsyncTestApp" asn:0x0-a90a9 pid:1313 refs=7 @ 0x7fba85370110 tried to be brought forward, but isn't in fPermittedFrontApps ( ( "LSApplication:0x0-0xab0ab pid=1318 "SecurityAgent"")), so denying. : LASSession.cp #1481 SetFrontApplication() q=LSSession 100004/0x186a4 queue
2/27/14 8:00:33.975 PM WindowServer: [cps/setfront] Failed setting the front application to blistTest, psn 0x0-0xa90a9, securitySessionID=0x186a4, err=-13066
This may be the impetus to change course and use the Authorization Frameworks but that will take a very long time and I need to help users in the mean time. Just can’t find anything that I could change here. I haven’t seen any mention of deprecating “with administrator privileges” and it does work in plain scripts but UI apps freeze.
You still haven’t made clear whether your app is sandboxed or not.
Also, that error seems completely unrelated to what’s in your do shell script command. It’s either something in loopCheck: or somewhere else in your code, or it’s some other app. You’re not trying to activate your app with an AS activate command, are you?
No sandbox - it is outside the “Store” but I have tried with it code signed, and without, with same results.
It’s the test app :
I don’t get the “isn’t in fPermittedFrontApps” unless it refers to the loop check code which updates the UI. It’s already in the foreground though and the code never gets past the do shell script - at least the logging stops there until rsync finishes. It would freeze up the UI if the process was launched in the foreground but it is in the background and the loop check timer watches the output till it’s done. It seems to stop at the do shell script line as if it is waiting for it to return.
The fPermittedFrontApps error doesn’t show up when it runs without privileges.
I just googled this so it looks like they have tightened up gate keep in 10.9.2 and somehow that is messing with the do shell script.
fPermittedFrontASNs" points to the new Gatekeeper Function Apple introduced in 10.8 and which changes the way background processes behave and are able to launch child processes that interact with the user interface.
Me too! the script is so simple now there isn’t much there to cause trouble, except the rsync command line but it is obvious that root privileges are what OS doesn’t like. 10.9.2 seems quite buggy to me any ways so maybe it is a bug.
I even tried creating helper script to run rsync and launched that with root privs instead but same hang ups.
Will find some other more drawn out command - just can’t think of any…
Ok, I tried ditto with admin prigs and same deal. Actually I did notice a black out in the log when running a short ls command too so I don’t think this is command dependent but about running processes in background. I googled around and a lot of people have seen those fPermittedFrontASNsfPermittedFrontASNs errors with installers that froze up.
Maybe someone on the rsync list will be encountering this but most of them are not running it from applescript.