On 22/08/2012, at 1:47 PM, Graham Cox <graham....@bigpond.com> wrote:
> The problem is that all of the files and folders INSIDE the folder created
> from the security bookmark are being disallowed by sandboxd
Here's a typical refusal report.
22/08/12 2:44:33.229 PM sandboxd[64627]: ([64596]) Artboard(64596) deny
file-read-data /Users/grahamcox/Documents/Artboard Test Files/Clip Art -
InAppPurchases/Design Elements Pack 1/GazetteScroll.svg
Artboard(64596) deny file-read-data /Users/grahamcox/Documents/Artboard Test
Files/Clip Art - InAppPurchases/Design Elements Pack 1/GazetteScroll.svg
[....]
Thread 0:
0 libsystem_kernel.dylib 0x0000000103e60fee __open + 10
1 CoreFoundation 0x00000001011ba0c9 _CFStreamOpen + 137
2 CoreFoundation 0x00000001011dbb76 CFReadStreamOpen + 86
3 Foundation 0x0000000100c86abd -[NSXMLParser
parseFromStream] + 44
4 Foundation 0x0000000100c86bed -[NSXMLParser parse]
+ 67
5 GCDrawKit 0x0000000100877972 -[DKSVGImporter
drawing] + 195 (DKSVGImporter.m:352)
6 GCDrawKit 0x00000001008cd7f5 -[DKSVGPreview
_dk_threadEntry] + 137 (DKSVGPreview.m:519)
7 CoreFoundation 0x000000010120ecac __invoking___ + 140
8 CoreFoundation 0x000000010120eb47 -[NSInvocation
invoke] + 263
9 Foundation 0x0000000100b5ed10
-[NSInvocationOperation main] + 34
10 Foundation 0x0000000100b56bb6
-[__NSOperationInternal start] + 684
11 Foundation 0x0000000100b5e3d1 __block_global_6 +
129
12 libdispatch.dylib 0x0000000103c7cf3d
_dispatch_call_block_and_release + 15
13 libdispatch.dylib 0x0000000103c790fa
_dispatch_client_callout + 8
14 libdispatch.dylib 0x0000000103c7a23e
_dispatch_worker_thread2 + 304
15 libsystem_c.dylib 0x0000000103cfaceb _pthread_wqthread +
404
16 libsystem_c.dylib 0x0000000103ce51b1 start_wqthread + 13
As you can see, I'm parsing XML (in fact SVG) on a thread which is queued using
an NSInvocationOperation. The object that handles this chore is passed a NSURL
which tells it which file to parse. I have been very careful to derive that URL
from the grandparent URL which was created by decoding a saved security-scoped
bookmark, but nevertheless this URL does not appear to inherit the security
scoping of its (grand)parent. So, despite the fact that I'm bracketing the
calls to [NSXMLParser parse] with the necessary incantations for security
scoping, sandboxd is still being the obstreperous refusnik that we all know and
loathe.
Is there something else I need to be doing to ensure derived URLs inherit the
security scoping of the parent URL?
I suspect that if I start and stop security scoping at this point on the
grandparent folder, it will probably work (something I need to try), but that
information is LONG gone by the time this method is asked to run by the
invocation (and why not? After all the URL is supposed to encapsulate all the
information it needs at this point, and with the exception of the sandboxing
mysticism, it does). There's also a question as to whether those methods are
thread-safe.
The code that derives these URLs is (simplified):
[self startSecurityAccess];
NSError* error;
NSArray* keys = [NSArray arrayWithObjects:NSURLIsDirectoryKey,
NSURLIsHiddenKey, NSURLPathKey, nil];
NSDirectoryEnumerator* all = [[NSFileManager defaultManager]
enumeratorAtURL:[self URL] <<---- this URL is derived from saved
security-scoped bookmark data
includingPropertiesForKeys:keys
options:NSDirectoryEnumerationSkipsSubdirectoryDescendants |
NSDirectoryEnumerationSkipsHiddenFiles
errorHandler:nil];
for( NSURL* sp in all )
{
NSNumber* isDirectory;
if([sp getResourceValue:&isDirectory
forKey:NSURLIsDirectoryKey error:&error])
{
if(![isDirectory boolValue])
{
// it's a file, use this URL <<-----
this URL does not inherit the necessary security scoping of the folder being
enumerated
}
}
}
[self stopSecurityAccess];
Here, my methods -startSecurityAccess and -stopSecurityAccess are wrappers
around the NSURL methods that also check they exist.
Note that this part appears to work in that without the start and
stopSecurityAccess methods, sandboxd barfs on the call into the NSFileManager,
but with them it allows it, so that shows that as far as it goes it is working.
--Graham
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
