On 29/05/2012, at 7:30 AM, Shawn Bakhtiar wrote: > First off (as much as I agree with the sentiment) isn't WTF profanity?
Well, it's in the eye of the beholder. I merely meant "Where To Find (information)" ;-) > Mark my words, to do this, will be the death of the App store. Users are > fickle. make them irate and they WILL find a way around, and as several > people have alluded to, user are notorious for clicking though (without > reading or understanding) only to get what they want done. It's one thing to > chroot an app on a server, where admins are the users, it's a WHOLE other > idea to have no technical users dealing with app signing issues, et al... > > Perhaps instead of creating M$ like controls that have you clicking > senselessly and endlessly to get something done, Apple should take a lesson > from history. in other words, how many Windows, Linux, etc, users actually > get hacked via downloaded applications VS. going to some malicious website > that uses OS/browser level vulnerabilities (how does sandboxing prevent, for > example, flashback)? When 99% of all security breaches in companies are as a > result of a disgruntled employee (from the inside), or sabotage (from the > inside) what does sand-boxing REALLY prevent? > > Nothing. It prevents nothing. It's nothing more then a warm fuzzy feeling, > that actually makes things worse, because people start believing the hype, > and relying on it as a method of security. So users become dumber, and take > more risky action which then continues an ever tightening cycle (noose around > the OS neck) of security, then one day, you go to log into your iMac and it > asks for a blood sample. > > Boycott the App store I say, until Apple comes to its senses. That isn't going to happen. I don't know about others' experiences with the App Store, but as an independent developer, it's been far more successful than we dared hope when it first opened. There's no way we could have done anywhere near as much business as we have, and withdrawing from it is only going to hurt us, not Apple. And that's if it even made sense to do so, which it doesn't - the horse is already out of the stable. If the App Store were launching tomorrow with this requirement such a boycott might stand a small chance. Sandboxing is a bit of a developer inconvenience, and while I tend to agree it really doesn't solve anything (or, it does, but the benefits are outweighed by the costs), it's not especially inconvenient for the user in the manner you're painting. In my case, assuming Apple are OK with the temporary exemptions to certain parts of the file system I'm asking for, the user will be none the wiser. In a few cases, where the user has put their iPhoto Library in a non-standard location, or has elected not to keep their photos in the iPhoto shoebox, I'll have to ask them if it's OK to peek at their iPhoto Library (or if their photos are all over the place, this would be unfeasible, so they'll just not be able to use that feature of our app). It's the usual 80/20% tradeoff - 80% of the users can be served without a hitch, leaving 20% with a few issues. Nobody has written a better analysis, critique and alternative suggestion for sandboxing than Wil Shipley: http://blog.wilshipley.com/2011/11/real-security-in-mac-os-x-requires.html But Apple haven't taken any notice of this as far as anyone can tell, and that's that. We're stuck with it. > I'd have a go see if you can even make the path and access the file at all > first, then we'll know if we have decoded the tech note properly. OK, back to the technical problem at hand. I have succeeded in getting this to work. I use getpwuid() to get the path to the user's home directory, append the standard location for the prefs file I want and I can read it into a NSDictionary (because I have the temporary exception privilege set). So that works alright - thanks for the help in getting me to understand what the documentation really is getting at. > CFPreferencesCopyAppValue indirects through the file path mapper and goes to > the local sandboxed version of ~/Library Yep, I see what's going on now. It's also why it was failing without a deny from sandboxd. What's annoying is that the parameters to this function give it enough information to realise that the intended file is outside of my sandbox (the fact that it's another app's ID) and could also isolate me in future from that app in itself being sandboxed. If iPhoto is sandboxed in future, its preferences will move and the getpwuid() technique will fail again. A correct fix to CFPreferencesCopyAppValue() would allow things to continue working seamlessly when that happens. Right now I have to look forward to my app breaking due to the fragility (and apparent lack of joined-up thinking) of this whole approach. --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
