AppleScript display image from URL problems (Sandbox)
211 views
Skip to first unread message
Red Rock Lobster
Sep 21, 2012, 5:45:56 AM9/21/12
to growld...@googlegroups.com
With Growl 2.0, I can't consistently send a notification with an image specified by a path. It seems to randomly work occasionally, but 95%+ of the time it does not.
If it is a problem with sandboxing, why on earth can't it read an image in my user domain?
9/21/12 5:37:27.085 AM sandboxd: ([502]) Growl(502) deny file-read-data /Users/myuser/Documents/Pictures/Image.jpg
Process: Growl [502]
Path: /Applications/Growl.app/Contents/MacOS/Growl
Load Address: 0x10d7cb000
Identifier: Growl
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: launchd [213]
Date/Time: 2012-09-21 05:36:54.232 -0400
OS Version: Mac OS X 10.7.5 (11G56)
Report Version: 7
Backtrace:
0 libsystem_kernel.dylib 0x00007fff902c4ad2 __open + 10
1 Foundation 0x00007fff9536cc35 _NSReadBytesFromFileWithExtendedAttributes + 210
2 Foundation 0x00007fff9536cb5a _NSReadBytesFromFile + 47
3 Foundation 0x00007fff95383546 -[NSData(NSData) initWithContentsOfFile:options:error:] + 193
4 Foundation 0x00007fff953eab48 -[NSData(NSData) initWithContentsOfURL:options:error:] + 238
5 AppKit 0x00007fff93fbd0bd NSImageRepNewDataFromFileURL + 273
6 AppKit 0x00007fff93beea48 +[NSImageRep _imageRepsWithContentsOfURL:expandImageContentNow:giveUpOnNetworkURLsWithoutGoodExtensions:] + 548
7 AppKit 0x00007fff93cefd2e +[NSImageRep _imageRepsWithContentsOfURL:expandImageContentNow:] + 24
8 AppKit 0x00007fff93cefd14 +[NSImageRep imageRepsWithContentsOfURL:] + 23
9 AppKit 0x00007fff93cefc8e -[NSImage initWithContentsOfURL:] + 31
10 Growl 0x000000010d7d6919 -[GrowlNotifyScriptCommand performDefaultImplementation] + 921
11 Foundation 0x00007fff95493c76 -[NSScriptCommand executeCommand] + 1110
12 Foundation 0x00007fff954ab6c8 -[NSScriptingAppleEventHandler handleCommandEvent:withReplyEvent:] + 217
13 CoreFoundation 0x00007fff9515c541 -[NSObject performSelector:withObject:withObject:] + 65
14 Foundation 0x00007fff953977c7 __-[NSAppleEventManager setEventHandler:andSelector:forEventClass:andEventID:]_block_invoke_1 + 101
15 Foundation 0x00007fff9539674e -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 283
16 Foundation 0x00007fff953965dc _NSAppleEventManagerGenericHandler + 105
17 AE 0x00007fff994bdc25 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned int, unsigned char*) + 200
18 AE 0x00007fff994bdb03 _ZL25dispatchEventAndSendReplyPK6AEDescPS_ + 38
19 AE 0x00007fff994bd9f7 aeProcessAppleEvent + 250
20 HIToolbox 0x00007fff931b9b69 AEProcessAppleEvent + 102
21 AppKit 0x00007fff93b6c9c5 _DPSNextEvent + 1247
22 AppKit 0x00007fff93b6c07d -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135
23 AppKit 0x00007fff93b689b9 -[NSApplication run] + 470
24 AppKit 0x00007fff93de4eac NSApplicationMain + 867
25 Growl 0x000000010d7d2355 main + 99
26 Growl 0x000000010d7ccc54 start + 52
Binary Images:
0x10d7cb000 - 0x10d86cff7 +com.Growl.GrowlHelperApp (2.0 - 2.0) <C6B01AE9-77C2-3139-B0E2-3103EC99B60F> /Applications/Growl.app/Contents/MacOS/Growl
0x7fff902ae000 - 0x7fff902cefff libsystem_kernel.dylib (1699.32.7 - compatibility 1.0.0) <66C9F9BD-C7B3-30D4-B1A0-03C8A6392351> /usr/lib/system/libsystem_kernel.dylib
0x7fff931a9000 - 0x7fff934d5fff com.apple.HIToolbox (1.9 - ???) <CCB32DEA-D0CA-35D1-8019-E599C8007AB6> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
0x7fff93b64000 - 0x7fff9476afff com.apple.AppKit (6.7.5 - 1138.51) <44417D02-6123-3FC3-A119-CE51BB4C3006> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x7fff950c6000 - 0x7fff9529aff7 com.apple.CoreFoundation (6.7.2 - 635.21) <62A3402E-A4E7-391F-AD20-1EF20236CE1B> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x7fff9535e000 - 0x7fff95677fff com.apple.Foundation (6.7.2 - 833.25) <22AAC369-B63C-3C55-8AC6-C3ECBA44DA7B> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x7fff994ba000 - 0x7fff994f9fff com.apple.AE (527.7 - 527.7) <B82F7ABC-AC8B-3507-B029-969DD5CA813D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
Daniel Siemer
Sep 21, 2012, 7:37:19 PM9/21/12
to Growl Discuss
Hey, so this was an oversight on our part with regards to sandboxing.
Unfortunately the direct method of pulling in an image file will
likely get disabled in a future release, as the nature of sandboxing
is more restrictive than what you are thinking even, and we won't be
able to get at anything outside our container. The other image
methods all still work (icon of file, app, and raw image data), and
there may be a workaround using the regular image data method where
you pass in a tiff. Im not entirely sure how to get said tiff data
into an applescript (apps which support applescripting often pass it
in, but from scratch, not so sure), but if you can't figure it out,
Ill look for the solution later this evening.
Unfortunately the direct method of pulling in an image file will
likely get disabled in a future release, as the nature of sandboxing
is more restrictive than what you are thinking even, and we won't be
able to get at anything outside our container. The other image
methods all still work (icon of file, app, and raw image data), and
there may be a workaround using the regular image data method where
you pass in a tiff. Im not entirely sure how to get said tiff data
into an applescript (apps which support applescripting often pass it
in, but from scratch, not so sure), but if you can't figure it out,
Ill look for the solution later this evening.
Daniel Siemer
Sep 22, 2012, 8:44:24 AM9/22/12
to Growl Discuss
So here is a bit of sample code, taken from here: http://stackoverflow.com/a/4233374
for bringing a file into the script as tiff data to pass to growl, and
avoid sandboxing issues.
tell application "System Events"
set imgfile to file "Test.jpg" of pictures folder
end tell
set imgfd to open for access imgfile
set img to read imgfd as "TIFF"
close access imgfd
tell application "Growl"
notify with name ¬
"NoteName" title ¬
"Note Title" description ¬
"This is a demo of showing an external to growl's sandbox image"
application name ¬
"TestScript" image img
end tell
While the command to us to notify is executed in our namespace, using
our code, the initial read in of that image data is handled by the
applescript system outside of us entirely.
for bringing a file into the script as tiff data to pass to growl, and
avoid sandboxing issues.
tell application "System Events"
set imgfile to file "Test.jpg" of pictures folder
end tell
set imgfd to open for access imgfile
set img to read imgfd as "TIFF"
close access imgfd
tell application "Growl"
notify with name ¬
"NoteName" title ¬
"Note Title" description ¬
"This is a demo of showing an external to growl's sandbox image"
application name ¬
"TestScript" image img
end tell
While the command to us to notify is executed in our namespace, using
our code, the initial read in of that image data is handled by the
applescript system outside of us entirely.
Red Rock Lobster
Sep 23, 2012, 5:11:06 AM9/23/12
to growld...@googlegroups.com
Please do not disable the direct method of pulling an image file in a future release. It's really absolutely essential. Please fix it with regards to applescript. Surely sandboxing can't be so restrictive. And if it works now in cocoa but not applescript, what's the issue? Surely the Apple big boys wouldn't have let Growl through the store for so long?
Red Rock Lobster
Sep 23, 2012, 5:33:33 AM9/23/12
to growld...@googlegroups.com
"If your app requires access to the user’s home directory in order to function, let Apple know about your needs using the Apple bug reporting system. In addition, be sure to follow the guidance regarding entitlements provided on the iTunes Connect website."
Daniel Siemer
Sep 23, 2012, 9:43:03 PM9/23/12
to Growl Discuss
Sandboxing is this restrictive. The developer documents you link to
also point out that such entitlements have to be justified, and we
cannot justify something that the user can work around with a few
lines of script.
Let me try and explain why its important we use sandboxing, as well as
why its important we don't request unneeded entitlements. While we
won't do anything malicious with your data, we do allow the running of
third party plugins, and these plugins run within Growl's namespace.
If Growl is nice and tightly sandboxed, those plugins only get access
to what apps already send us. If we were to say, request and be
granted the ~/ read entitlement as you say we should try, when it
wasn't really needed, a malicious plugin could gain access to all your
personal data, and send it off someplace (one should still only run
plugin's from trusted sources, but we can do our part by keeping the
sandbox as tight as can be).
As for "This works in cocoa", no, it doesn't. Growl.app cannot read
these files regardless of whether we were told to do so by any of our
frameworks, a generic GNTP sender using the URL command (we can read
remote URL's though), or an applescript. GrowlNotify does allow this,
but it reads the data in itself, before sending it off to Growl as a
data stream. GrowlNotify, unlike the ApplesScript commands, is
executed outside our namespace, and is not sandboxed.
On Sep 23, 4:33 am, Red Rock Lobster <redrocklobs...@gmail.com> wrote:
> > "If your app requires access to the user’s home directory in order to
> > function, let Apple know about your needs using the Apple bug reporting
> > system <https://bugreport.apple.com/>. In addition, be sure to follow the
> > guidance regarding entitlements provided on the iTunes Connect<https://itunesconnect.apple.com/>
> > website."
>
> http://developer.apple.com/library/mac/#documentation/Security/Concep...
also point out that such entitlements have to be justified, and we
cannot justify something that the user can work around with a few
lines of script.
Let me try and explain why its important we use sandboxing, as well as
why its important we don't request unneeded entitlements. While we
won't do anything malicious with your data, we do allow the running of
third party plugins, and these plugins run within Growl's namespace.
If Growl is nice and tightly sandboxed, those plugins only get access
to what apps already send us. If we were to say, request and be
granted the ~/ read entitlement as you say we should try, when it
wasn't really needed, a malicious plugin could gain access to all your
personal data, and send it off someplace (one should still only run
plugin's from trusted sources, but we can do our part by keeping the
sandbox as tight as can be).
As for "This works in cocoa", no, it doesn't. Growl.app cannot read
these files regardless of whether we were told to do so by any of our
frameworks, a generic GNTP sender using the URL command (we can read
remote URL's though), or an applescript. GrowlNotify does allow this,
but it reads the data in itself, before sending it off to Growl as a
data stream. GrowlNotify, unlike the ApplesScript commands, is
executed outside our namespace, and is not sandboxed.
On Sep 23, 4:33 am, Red Rock Lobster <redrocklobs...@gmail.com> wrote:
> > "If your app requires access to the user’s home directory in order to
> > function, let Apple know about your needs using the Apple bug reporting
> > guidance regarding entitlements provided on the iTunes Connect<https://itunesconnect.apple.com/>
> > website."
>
> http://developer.apple.com/library/mac/#documentation/Security/Concep...
Red Rock Lobster
Sep 24, 2012, 10:54:38 AM9/24/12
to growld...@googlegroups.com
Fine, thanks for the explanation
I would only add that there are a lot of older apps and scripts that will fail because of this, and never be updated. Note that a notification sent from AS that uses an image path will fail totally, not just not put up a notification without an image. May you can fix that at least. In my view that's a good justification to access user domain but I know Apple may not bite. I think the whole sandbox thing is bunk, but that's my dinosaur view, I guess.
I the meantime, if you notice this, could you please address my 2 other open bug threads, too? Thanks.
1. issue of click throughs not working after time period:
Daniel Siemer
Sep 24, 2012, 11:36:42 AM9/24/12
to Growl Discuss
We will make sure that the notifications don't simply fail in a future
version, but it will likely resort to filling in a generic icon. I
have filed this as http://code.google.com/p/growl/issues/detail?id=529
>
> 2. prowl settingshttps://groups.google.com/forum/?fromgroups=#!topic/growldiscuss/fNVw...
version, but it will likely resort to filling in a generic icon. I
have filed this as http://code.google.com/p/growl/issues/detail?id=529
On Sep 24, 9:54 am, Red Rock Lobster <redrocklobs...@gmail.com> wrote:
> Fine, thanks for the explanation
>
> I would only add that there are a lot of older apps and scripts that will
> fail because of this, and never be updated. Note that a notification sent
> from AS that uses an image path will fail totally, not just not put up a
> notification without an image. May you can fix that at least. In my view
> that's a good justification to access user domain but I know Apple may not
> bite. I think the whole sandbox thing is bunk, but that's my dinosaur
> view, I guess.
>
> I the meantime, if you notice this, could you please address my 2 other
> open bug threads, too? Thanks.
>
> 1. issue of click throughs not working after time period:https://groups.google.com/forum/?fromgroups=#!topic/growldiscuss/AzhA...
> Fine, thanks for the explanation
>
> I would only add that there are a lot of older apps and scripts that will
> fail because of this, and never be updated. Note that a notification sent
> from AS that uses an image path will fail totally, not just not put up a
> notification without an image. May you can fix that at least. In my view
> that's a good justification to access user domain but I know Apple may not
> bite. I think the whole sandbox thing is bunk, but that's my dinosaur
> view, I guess.
>
> I the meantime, if you notice this, could you please address my 2 other
> open bug threads, too? Thanks.
>
>
> 2. prowl settingshttps://groups.google.com/forum/?fromgroups=#!topic/growldiscuss/fNVw...
Red Rock Lobster
Sep 24, 2012, 3:10:20 PM9/24/12
to growld...@googlegroups.com
On Monday, September 24, 2012 11:36:46 AM UTC-4, Daniel Siemer wrote:
We will make sure that the notifications don't simply fail in a future
version, but it will likely resort to filling in a generic icon. I
have filed this as http://code.google.com/p/growl/issues/detail?id=529
Thanks.
Reply all
Reply to author
Forward
0 new messages