On Aug 29, 2012, at 12:17 PM, Mike Abdullah wrote: > > On 26 Aug 2012, at 03:02, Graham Cox <graham....@bigpond.com> wrote: > >> >> On 25/08/2012, at 8:14 PM, Mike Abdullah <cocoa...@mikeabdullah.net> wrote: >> >>> I had a funny feeling you were going to point the finger at us ;-) >>> Checked out the code, and I can assure you, iMedia is doing this: >>> >>> NSURL* url = [NSURL URLWithString:library]; >>> NSString* path = [url path]; >>> >>> Where library is a string retrieved from the prefs to note where a media >>> library lives. I continue to be pretty sure no path-based APIs accept URL >>> strings. >> >> >> Well..... >> >> This code was based on a very old version of the iMedia code, probably from >> 2008 or 9. It was certainly heavily modified when I adapted it to my own >> structures, but this part I kept intact. In fact, it still retains remnants >> of a workaround for some other Cocoa bug along with the comments pertaining >> to it, which is why I know I never altered it. Perhaps the behaviour just >> happened to work... or perhaps back then Apple were not storing a URL in the >> prefs but a path? > > The latter seems more likely. The thing is this: > > file://localhost/example.png > > is a perfectly valid relative path, going: > > file/ > localhost > example.png > > (if you were browsing in the Finder) >> >> It's very probable that it got changed later - I haven't checked to see what >> the current version does. Presumably, it was updated to use NSURL at some >> point, but the version I used was path-based. >> >> I hadn't realised that you were associated with Karelia. I wasn't pointing >> the finger, just trying to understand what the issue was. I accept that in >> porting the code Karelia no longer have any responsibility for it. What have >> been your experiences with sandboxing the iMedia browser? > > No worries; the "finger-pointing" was meant mostly in jest. We're getting > there on sandboxing it. Mostly not tooooo painful, but held up by a bookmarks > bug at present.
Actually, people over on the AppleScript list are already running into "this script is signed by an unknown developer", or apps based on AppleScript are simply crashing if the Mountain Lion security settings are set to only run apps from the App Store. But before anyone reads too far, I am making certain assumptions that may indeed be false. That iOS and Mac OS app Sandboxing is absolutely required and you can't make apps without it enabled, whether the apps are destined for the App store or not. If my assumption is incorrect and Sandboxing is not required for non App Store apps, (Mac OS or iOS) please let me know. If that is the case, then the trick is finding the documentation for file access without the Sandboxing restrictions. But Mike, maybe you can answer a question for me. Why must Sandboxing's access to the file system be locked down to be within an app and document type folders - on iOS and on the Mac? Why can't we write preferences where every Mac app has written them before and limit writing to just the contents of a folder that matches the app's bundle? Instead of forbidding access to all but the approved folders and to folders inside the app, why not just lock the app's access based on file and folder permissions like we already have, and by restricting access to: user: - The preferences folder for the current app bundie ID: /User/currentUser/Library/Preferences/ + preference folders that are not its own within the current user folder/domain + app bundle ID - Any folder within a folder in the user's Library folder + the app bundle ID folder: /User/currentUser/Library/*/anyFolderName/ + folder with the app bundle ID root: - root/Library - root/System - those other unix folders off of root How does "every app is an island" make the system more secure and the user experience and the developer experience better by restricting access to only the app's content folders, the music, documents, addresses and so on? How does preventing an application (code signed or not) from writing to the /Users/currentUser/Library in a sub folder reserved for the app actually help make a better experience? And if you want to write an app with an Enterprise or Personal license and will never distribute the app over the App Store, why can we not bypass this restriction? What's worse, as this gets promoted, documentation for how to write and read files to the file system gets harder to find. Additionally, execs in companies who will have to support Macs and iOS devices on Enterprise level will declare that for security reasons the Gatekeeper restriction on Macs must be locked in the "Only allow apps from the App Store". Why I care about this. In the past, I've created a serialized app that is an automated suite of Xcode wrapped AppleScripts and OC classes that talk between 5 apps and write files into folders at the root, so that the files are purposely independent of whichever user is running the app. Back at Verizon, it saved us several million dollars easy in time to market and granted us the ability to push product (FiOS TV) onto multiple platforms (5+ vs 1) within the middle of a 30% headcount cut. Having read the dev docs about the restrictive nature of sandboxing I don't see any way that apps like this will even be possible on the Mac OS in the future. If that's simply because of dense documentation, well, that's another issue, but I really, really, really hope I'm wrong here. Why Sandboxing needs to be as restrictive as it is for Mac OS and iOS has still not been made painfully obvious to me. It simply looks like creative developers who want to read and write files (no one does that, do they?) are just a little more shackled by Apple's attempt to apply security to the OSes. Note that I am using these docs as references: http://developer.apple.com/library/ios/#DOCUMENTATION/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW2 http://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html http://securityevaluators.com/files/papers/apple-sandbox.pdf _______________________________________________ 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
