Give iterm full disk access3/27/2023 Presumably UAT pinning is the internal term for the user listings set in Privacy. The first time that you connect to a Mac using ssd, sshd-keygen-wrapper isn’t in the Full Disk Access list, which securityd complains about in the log:Ĭould not enable test hierarchy: no UAT pinning preferences set It has in the past acted as a proxy for ssh/sshd in configuring firewalls, and here it also seems to act as a proxy for sshd. Sshd-keygen-wrapper is a tiny bit of code which is inevitably undocumented, and concerned with generating keys for ssh. TCC constructs the attribution chain for this with the requester (REQ) as /usr/libexec/sandboxd, the access requested (ACC) as /bin/ls, and the responsible process (RESP) as /usr/sbin/sshd with a responsible path of /usr/libexec/sshd-keygen-wrapper. When you ask, for example to list the contents of the ~/Library/Calendars folder using ls, in the first instance a synchronous request is made to for the service kTCCServiceSystemPolicyAllFiles and function TCCAccessRequest. With an ssh connection to a Mac, asking to list or view the contents of items which are not protected by TCC takes place through opendirectoryd and supporting services, and doesn’t involve TCC at all. Note that removing the sshd-keygen-wrapper item from the list sets it back to the first state, effectively enabling Full Disk Access: it does not prevent access to protected data at all. The only control that the user has is enabling and disabling the sshd-keygen-wrapper in the Full Disk Access list, which has the effect of toggling access to protected data for that user. It is only when Privacy settings are in the last state that access to protected data will be refused. When you try to access that Mac using ssh, if it is in either of the first two states, macOS will automatically give ssh Full Disk Access. accessed and permission now stopped, with sshd-keygen-wrapper listed but not ticked.accessed and permission granted, with sshd-keygen-wrapper listed and ticked.never accessed, and sshd-keygen-wrapper is absent from the Full Disk Access list.It is particularly interesting, as it is one of the rare exceptions to the rule that only user interaction can modify the lists in Privacy: here, TCC adds its own item to the Full Disk Access list without any user warning or consent.Īs far as access by the secure shell is concerned, Macs are in one of three states: Whether this is a bug or a feature, I’ll leave you to judge when I explain how this works. Despite several sessions looking carefully at this, even studying the logs of both client and server during ssh connections, I was completely wrong.įor the avoidance of any doubt, Mojave 10.14.1 update hasn’t changed the behaviour of ssh with respect to privacy protection: if you enable Remote Login to your Mac in its Sharing pane, then anyone who gains access as a user using ssh can see all that user’s private data. I’m still not quite sure what happened, but I had mistakenly concluded that Apple had changed the behaviour of the secure shell, ssh, with respect to privacy protection. I apologise again for the interruption to my regular weekly article Last Week on My Mac, which appeared then disappeared yesterday.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |