Allan,
> On Apr 24, 2020, at 00:14, Allan Odgaard via Cocoa-dev
> wrote:
>
> On 24 Apr 2020, at 9:51, Gary L. Wade wrote:
>
>> Have you tried a speed check with just iCloud turned off but internet on?
>
> I have tried with iCloud disabled, internet disabled, and SIP disabled.
Have you tried something like the Little Snitch app to Confirm there is network
access to Apple and determine what network activity is going on?
Sandor
>
> Only the latter two removes the delay. Also, the issue happens for
> ~/Downloads which is not an iCloud folder.
>
> Furthermore, the stack dump seems fairly clear about what goes on.
>
> For the records, I’m reposting my findings here with stack dump.
>
> This is actually from Transmission.app, in Preferences you can configure
> download folders, so I selected ~/Documents, ~/Downloads, and ~/Desktop,
> which are the 3 “protected” folders. I then ran a spindump when opening
> Preferences, which has to obtain display name and icon for these folders (to
> show in the UI), which results in 620 ms spent in NSWorkspace’s iconForFile:
> (getattrlist).
>
>62 -[NSWorkspace iconForFile:] + 80 (AppKit + 3229058) [0x7fff32ee1582]
>62 -[NSWorkspace _iconForURL:] + 100 (AppKit + 3229205) [0x7fff32ee1615]
>62 _GetIconRefFromURL + 26 (LaunchServices + 233122) [0x7fff370edea2]
>62 BindingManager::CreateWithURL(__CFURL const*, bool) + 28
> (LaunchServices + 233204) [0x7fff370edef4]
>62 BindingBlueprint::BindingBlueprint(__CFURL const*) + 78
> (LaunchServices + 233350) [0x7fff370edf86]
>62 BindingBlueprint::copyURLProperties(__CFURL const*) + 50
> (LaunchServices + 233496) [0x7fff370ee018]
>62 CFURLCopyResourcePropertiesForKeys + 111 (CoreFoundation + 555324)
> [0x7fff3599493c]
>62 _FSURLCopyResourcePropertiesForKeysInternal(__CFURL const*, __CFArray
> const*, void*, __CFError**, unsigned char) + 1110 (CoreServicesInternal +
> 60765) [0x7fff4ecb0d5d]
>62 prepareValuesForBitmap(__CFURL const*, __FileCache*,
> _FilePropertyBitmap*, __CFError**) + 363 (CoreServicesInternal + 17604)
> [0x7fff4eca64c4]
>62 __getattrlist + 10 (libsystem_kernel.dylib + 5746) [0x7fff6fa19672]
>*62 hndl_unix_scall64 + 22 (kernel + 819718) [0xff80002c8206]
>*62 unix_syscall64 + 647 (kernel + 7894519) [0xff80009875f7]
>*62 getattrlist + 136 (kernel + 3512472) [0xff8000559898]
>*62 ??? (kernel + 3512820) [0xff80005599f4]
>*62 ??? (kernel + 3501529) [0xff8000556dd9]
>*62 ??? (kernel + 3490836) [0xff8000554414]
>*62 mac_vnode_check_access + 154 (kernel + 9093082) [0xff8000aabfda]
>*62 hook_vnode_check_access + 167 (Sandbox + 39552) [0xff7f823a7a80]
>*62 sb_evaluate + 5004 (Sandbox + 67658) [0xff7f823ae84a]
>*62 approval_response_wait + 142 (Sandbox + 154851) [0xff7f823c3ce3]
>*62 __WAITING_ON_APPROVAL_FROM_SANDBOXD__ + 23 (Sandbox + 155134)
> [0xff7f823c3dfe]
>*62 ??? (kernel + 6855402) [0xff8000889aea]
>*62 thread_block_reason + 175 (kernel + 1317935) [0xff8000341c2f]
>*62 ??? (kernel + 1324017) [0xff80003433f1]
>*62 machine_switch_context + 200 (kernel + 2388456) [0xff80004471e8]
>
> Looking at sandboxd, it has 3 queues spending respectively 150, 160, and 310
> ms in TCCAccessPreflightWithAuditToken (so total time spent there is 620 ms),
> which I would guess is processing Transmission’s request for reading the
> extended attributes for the 3 paths.
>
> But sandboxd itself does tccd_send_message, so it seems to call upon the tccd
> daemon.
>
> There are two tccd instances running on my system, each have two queues with
> 150 ms spent in SecCodeCheckValidityWithErrors (so a total of 600 ms spent in
> tccd).
>
> This code though again seems rely on another process by calling:
> securityd_send_sync_and_do (which does XPC).
>
> But I can’t find out which process it communicates with. I don’t know if this
> could be launched-on-demand and therefore not part of the spindump report?
>
> But to summarize, first call of getattrlist/getxattr for a protected folder
> seems to trigger application signature validation (makes sense), which, at
> least on my system, appears to involve network access, reminiscent of what
> goes on with execve().
>
> Given the above, I don’t think anyone can dispute that this is what goes on,
> and it would be extremely strange if this is not “by design”.
>
> What might be a bug is that the check does network access, but you don’t just
> put such code in by mistake, so obviously there must be certain times where
> it needs network access, and as demonstrated with execve(), Apple is not shy
> of making low-level system APIs contact Apple’s servers as part of their SIP.
>
> The million dollar question is now: What are the conditions under which it
> must have network access? and/or why does it seem to trigger all the time on
> my system?
>
