> Le 14 sept. 2015 à 01:33, Ed Wynne <ar...@phasic.com> a écrit :
> 
> 
> 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.

No trying to write in a protected area in the first place is even better. You 
don’t need to check, just don’t do it.

> 
>> - 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.com


_______________________________________________

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

Reply via email to