Comment by cyberax

Comment by cyberax 2 days ago

7 replies

View on Hacker News

I couple of months ago, I wasted about 4 hours debugging issues with my app. Command-line scripts didn't work properly for some reason, while my IDE worked fine.

Turned out that I either missed or accidentally denied the permission to access local networks for iTerm. So the `curl` utility installed from Homebrew was silently failing, while the system-provided `/usr/bin/curl` worked fine. Because it has special permission from Apple.

Can I just give the same permission to iTerm? Nope. We are not worthy of that power, and must re-affirm permissions every 30 days for all non-Apple software.

Oh, and these permission popups happen at random moments, including during presentations or meetings. And if you don't accept them, they are silently denied.

tpmoney 2 days ago

> Can I just give the same permission to iTerm? Nope. We are not worthy of that power, and must re-affirm permissions every 30 days for all non-Apple software.

Not sure what permission you're referring to or what your curl script is trying to do but `/opt/homebrew/opt/curl/bin/curl http://www.google.com` works just fine on Tahoe from both iTerm2 and ghostty. Looking through the various permission grants, the only one they both have in common is "App Management". They share some file permission grants, but where as iTerm has full disk access, ghostty only has Downloads and removable media. In the past I've found I've needed to add terminals like iTerm to the Developer Tools permission, but ghostty isn't in there currently and curl is still working just fine. And in none of these cases have I ever needed to re-affirm the permission every 30 days.

Any chance you have "disclaim ownership of children" setting enabled in iTerm? Maybe if iTerm is not allowing child processes to use its own permissions, you're having to re-authorize curl specifically (and it's getting updated about once every 30 days?)

> And if you don't accept them, they are silently denied.

This is IMO the correct behavior. If something asks for permission and it's not explicitly granted, then the default should always be denied.

Reply View 6 replies
  • cyberax a day ago

    > Not sure what permission you're referring to or what your curl script is trying to do but `/opt/homebrew/opt/curl/bin/curl http://www.google.com` works just fine on Tahoe from both iTerm2 and ghostty.

    Mwwahahaha. Yep. Curling something neutral like google.com worked fine for me as well. That's how I was verifying that everything was OK.

    Now try to do "curl https://192.168.0.1" (or whatever is your local router's IP). It will trigger this request: https://imgur.com/a/tMAApfB

    The permission in question is called "Local Network", you can find it in the "Security" section in the control panel. Yeah, their names don't match.

    Oh, and negative entries are NOT listed in that panel. So if you deny the request, there is NO indication of that. Anywhere. Logs will also be empty.

    > This is IMO the correct behavior. If something asks for permission and it's not explicitly granted, then the default should always be denied.

    The keyword is SILENTLY. The permission requests should be logged and made available in a central location, where they can be reviewed.

    It's literal recursive WTF. When you start looking at it, it gets worse and worse.

    Reply View 5 replies
    • tpmoney 14 hours ago

      So I thought that might be the dialog you're talking about which is why I thought it was weird that ghostty didn't have it and curl seemed to work just fine. I also could swear that it did show you rejected apps in the list just with the permission turned off.

      After experimenting a bit, it seems like:

      1) You're right that it doesn't show the rejected apps in the list. Seems like the only way to find that is to query the tcc sqlite db.

      2) The permission does apply equally to the built in `curl` as it does to the homebrew installed curl.

      3) What it doesn't apply to apparently is the gateway address on your network, regardless of which app you use.

      4) It also doesn't apply to all "private" IP space addresses, just ones that are on your subnet. So for example, I have an IOT subnet on my network on its own VPN with a route in the gateway for accessing it from some specific devices on the primary LAN. Without the permission, I can ping and curl (with both the built in and homebrew versions) all of the devices on the IOT subnet. But I can't ping or curl (again with either version) any of the devices on the LAN subnet. Turn the permission on and I can hit everything on the local subnet fine from all the devices.

      5) I also validate that the above rules are true even for an application (alacritty in this case) that had never been given permission (in case setting and then removing the permission did something odd)

      > The keyword is SILENTLY. The permission requests should be logged and made available in a central location, where they can be reviewed.

      This I agree on, the rejected apps should show in the privacy permissions, even if in a collapsed tab/pane so that you can review later. I could swear it used to do this, but maybe I'm thinking of iOS which does do that.

      Reply View 1 reply
      • cyberax 10 hours ago

        > 2) The permission does apply equally to the built in `curl` as it does to the homebrew installed curl.

        I think this might have been fixed? `codesign -dvvv /usr/bin/curl` no longer prints anything about permissions. I definitely remember investigating this particular point.

        > 3) What it doesn't apply to apparently is the gateway address on your network, regardless of which app you use.

        Doesn't work for me. I can't ping or HTTP into my gateway from a terminal app that doesn't have this permission.

        Edit: apparently pinging the gateway works if you're on WiFi. But not with wired Ethernet. Wow.

        Reply View 0 replies
    • datadrivenangel a day ago

      This permission is so weirdly named and scary, and the applications never tell you why they're requesting it... on iOS it would be against the developer guidelines...

      Reply View 2 replies
      • cyberax a day ago

        Yep. MacOS is against the iOS guidelines.

        Because it's a macOS dialog, not something that is controlled by applications.

        Reply View 0 replies
      • cyberax a day ago

        BTW, what's even worse is that this permission is utterly useless. A malicious app can just use the system `curl` to bypass it.

        Meanwhile, the genuinely scary "Accessibility" permissions that allow spying over the entire system are granted once and never need to be re-approved.

        Reply View 0 replies