2 Replies
      Latest reply on Oct 17, 2019 7:48 AM by john daniel
      khoyt Level 1 Level 1 (0 points)

        I have an existing daemon and I need to figure out how to get full disk access.  We currently use launchD with the KeepAlive and RunAtLoad keys.  From the readme, KeepAlive is on the no-no list.

         

        I'm certainly open to any and all suggestions on how to get the access we need. 

         

        Yes, we need to run even when users are NOT logged in.

        Yes, we need to be able to access all files.

         

        It's a command line tool that is NOT part of an 'application'.

        • Re: Where is the updated documentation for LaunchD and Catalina?
          eskimo Apple Staff Apple Staff (12,285 points)

          Yes, we need to be able to access all files.

          FYI, that’s not an option, even on systems prior to 10.14.  See the discussion of data vaults on this thread.

          I have an existing daemon and I need to figure out how to get full disk access.

          There’s no API to programmatically get (or even request) full disk access.  Rather, the user must enable it in System Preferences.

          Share and Enjoy

          Quinn “The Eskimo!”
          Apple Developer Relations, Developer Technical Support, Core OS/Hardware
          let myEmail = "eskimo" + "1" + "@apple.com"

          • Re: Where is the updated documentation for LaunchD and Catalina?
            john daniel Level 3 Level 3 (490 points)

            For this app, I suggest bundling it inside and app bundle. The UI of the bundle doesn't have to do much. Maybe it can install itself, uninstall itself, or repair itself. This is more of a social problem rather than a technical one. Apple requires the user go to System Preference to enable Full Disk Access. Therefore, Apple has inserted the user into your app. You have to account for that. You need to have an app that the user can find, with a nice icon, and manage by copying it to the Applications folder. Your UI can do all the heavy lifting internally to install launchd daemons, etc. But now you have to deal with the human and make it easy for them to use your app, or even just find it System Preferences.

             

            Going forward, you might want to review exactly what kind of software you are developing, and for whom. I always ask people, how would your app work on iOS? That is the future you need to plan for. Apple keeps adding these security hoops with each iteration of the operating system. If you have existing users invested in your product, you can contact them, update the app, etc. and help them manage the changes to the operating system. But these changes may constitute an insurmountable barrier to any new customers. End users simply don't know anything about security restrictions, full disk access, sandboxes, nothing. When it breaks, doesn't work, or they get confused, they are going to blame you, not Apple. There are many old-school Mac utility apps that will simply not be viable in the future. They are going to go away. The future is an iOS future.