Dealing with "deny file-read-data /path/to/icns" when injecting into sandboxed app
Closed this issue · 7 comments
I'm using a modified version of your simbl plugin (as described here), and I was wondering how you deal with restrictions when injecting into sandboxed apps (for the save/open panel). For example TextEdit only has the "com.apple.security.files.user-selected.read-write" entitlement so we cannot just read the image at some arbitrary path to create the appropriate NSImage.
What exactly is the arbitrary location?
- I don't see any issues with loading images from locations like Desktop/Documents.
- Couldn't you just move the image somewhere the app has access to and then load form there?
I think the issue is unrelated to the entitlements, since it doesn't work with the save dialogs on a plain (non-sandboxed) app either (as an example, if I open up "Console.app" and hit cmd-O the sidebar item images in the open panel are not replaced), although the extension is indeed loaded into console.app (Console doesn't seem to use the openAndSavePanelService
so that too is moot).
My fork does seem to cover both cases of TSidebarItemCell
and FI_TSidebarItemCell
as yours does (https://github.com/krackers/colorfulSidebar_9/blob/master/colorfulSidebar9/colorfulSidebar9.m), so I'm unsure what the issue might be.
I'll close the issue for now since it seems to be an issue only with my forked version.
10.9, which is another reason why I closed the issue since I don't want to waste your time trying to debug this.
Have you tried moving the image to a location it can be read?
On 10.9 at least Console is not sandboxed so reading the image isn't an issue there, and the extension is injected without errors. The sidebar is still not updated though which makes me think something else is awry.
So if you're using colorfulSidebarX
I think you should be able to work around this by placing the image inside the bundle.
Example:
/Library/Application Support/MacEnhance/Plugins/colorfulSidebarX.bundle/Contents/Resources/mydankimage.png
And then adding it to the appropriate icons.plist
with a key like this:
<key>mydankimage.png</key>
<array>
<string>~/Pictures</string>
</array>
To add the functionality to your own build you'd need to add this part into
+ (void)setUpIconMappingDict
// Check if it's a bundle resource
if (image == nil) {
NSString *keyPath = [key stringByDeletingPathExtension];
NSString *keyExt = [key pathExtension];
NSString *bundleResource = [[NSBundle bundleForClass:self] pathForResource:keyPath ofType:keyExt];
image = [[NSImage alloc] initWithContentsOfFile:bundleResource];
}
The images should then load.
Yeah that helps solve the sandboxing issue, although the icon still doesn't load. I think the issue is that FI_TSidebarItemCell is not loaded until the save panel is first opened, by which point all the swizzling has been done. (I verified this by using FScript to inspect the loaded classes before/after the save panel was opened).
EDIT: Oh I think your colorfulSidebarX takes care of this by swizzling NSImage itself and then checking if the superview
matches FI_TSidebarItemCell
. I'll switch to using this approach, which should make things work. Thank you!
Yup, I was able to get it working by swizzling NSImage using
@implementation wb_NSImageView
- (void)_setImageView:(id)arg1 {
NSObject *aSuper = [self superview];
if (aSuper) {
if ([[aSuper className] isEqualToString:@"FI_TListHeaderCellView"]) {
dispatch_once(&ONCE_FI_TSidebarItemCell, ^ { ZKSwizzle(wb_TSidebarItemCell, FI_TSidebarItemCell); });
}
}
ZKOrig(void, arg1);
}
@end
(I had to check if superview was FI_TListHeaderCellView
because attempting to check the classname of self always returned NSImageView
. I'm not sure why this is, since i would expect it to return FI_TImageView
or something).