• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Sandboxing die.die.die
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sandboxing die.die.die


  • Subject: Re: Sandboxing die.die.die
  • From: Graham Cox <email@hidden>
  • Date: Wed, 22 Aug 2012 15:03:49 +1000

On 22/08/2012, at 1:47 PM, Graham Cox <email@hidden> 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 (email@hidden)

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:

This email sent to email@hidden

References: 
 >Sandboxing die.die.die (From: Graham Cox <email@hidden>)

  • Prev by Date: iOS IB Object
  • Next by Date: Re: Sandboxing die.die.die
  • Previous by thread: Re: Sandboxing die.die.die
  • Next by thread: Re: Sandboxing die.die.die
  • Index(es):
    • Date
    • Thread