On Sep 13, 2015, at 5:47 PM, Stephane Sudre <dev.iceb...@gmail.com> wrote: >>>> That document doesn't mention an API… >>> Hence, since that is the current documentation, my conclusion : “Don’t >>> think so”. >> There is an API. Much like with sandboxing it just may not be public, which >> means it is inappropriate for discussion here. I’m not sure why Apple >> considers this kind of thing off limits, but that is inappropriate for >> discussion here as well. > > I must be missing something but why should there be an API?
There are many reasons. For example, writing to the areas SIP protects typically requires authorization. Not offering the user an impossible action is a much better UX than letting them go through the trouble of authenticating only to have it fail anyway. > - determining whether SIP is on requires to check whether the running > OS on 10.11 or later. This check is not sufficient since SIP can be disabled. > Also it could done by parsing the output of $ > csrutil status but this would assume the output format will not change > in the future. Exactly, which makes this a bad option. > - determining whether you can write to a file or folder can be done > with the usual BSD, Cocoa APIs, can't it? Yes and no. Not having the beta (er, GM seed) handy to check, I honestly don’t know if the R/W file system permissions are reported differently when SIP is present and enabled. Based on how sandboxing operates, I would assume they are not. But that isn’t to say some things won’t be detectably different, which was the point of my suggestion about secondary checks. They might be possible, but they are still a bad option since they usually fall into the category of undocumented side effects. > - knowing which parts of the file hierarchy are protected is covered > by the documentation (Interestingly I've just discovered that > /Applications/Utilities is a no trespassing area). Except they aren’t protected when SIP is disabled, which was the point of the OP’s question. -Ed _______________________________________________ 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
