2 Replies
      Latest reply on May 16, 2019 1:08 AM by eskimo
      rhythmicfistman Level 1 Level 1 (0 points)

        In an installer-free, non MAS mac app, I need to let the user do the equivalent of

        sudo (cp MyAudioDriver.driver /Library/Audio/Plug-Ins/HAL/ && killall coreaudiod)


        so they request the installation of the optional component, see the standard “[App X] wants to make changes, enter a password to continue”  and the above happens with elevated privileges.


        After looking at the sample code `SMJobBless`, `BetterAuthorizationSample` and `EvenBetterAuthorizationSample` (we don’t talk about plain  `AuthorizationSample` any more), the picture that I’m getting is that the solution is a mixture of


          1. use SMJobBless to install privileged helper app managed by launchd (this - hopefully - can do the one-liner above)

          2. code signing & (mutual?) whitelist to establish trust between app and helper

          3. XPC for communication between helper and app (hi, this is the app, please install the thing)


        This seems so complicated, is this really the way to do what I want in a non-deprecated fashion? The client justifiably points out that requesting elevated permissions for Accessibility scripting is very easy, but there’s a dedicated API for that.


        I got the SMJobBless sample code working, and confusingly, its security dialog says “[App X] wants to install a helper app, enter password” which is not the message I want to give, so hopefully there’s some plist customisation somewhere where I can say “[App X] wants to install an audio component”.


        Am I on the right path?


        I have many doubts and questions


        • XPC to a privileged app is apparently not supported (mentioned here: http://atnan.com/blog/2012/02/29/modern-privileged-helper-tools-using-smjobbless-plus-xpc/)
        • can I shell out to the one liner script? it's codesigned...
        • aren't helper apps supposed to be long running?
        • every other app seems to have the "[App X] wants to make changes" dialog. Does that mean they're using the deprecated AuthorizationExecuteWithPrivileges()? or are they asking AppleScript to run a shell script with elevated privileges?
        • the calling app is not a bundle, it's just a binary/CLI tool, that acts as a plug-in for an electron .app package/bundle. can the CLI tool communicate with the helper?
        • I'm no security expert, but having a helper app/server running as root & performing commands (in this case file copies to directories owned by root) on behalf of my app seems kinda... insecure.
        • Re: SMJobBless to sudo install HAL Plugin
          john daniel Level 3 Level 3 (380 points)

          The idea is that the helper app is more secure because all it can do, in theory, is copy this one file to that one location.


          Unfortunately, there is no good answer here.


          Clearly, Apple wants to discourage apps from running as root. In some future macOS update, it seems likely that this will be enforced, much like iOS today. By the same token, I can't imagine that Apple is all too interested in supporting 3rd party audio plugins. I always tell people, "how would you accomplish the same task on iOS today?" If the answer is laughter, then you are in a high risk line of development.


          Given that your product may very well be summarily terminated within 3 weeks - 3 years, how much do you really care about doing it all the "right" way? My suggestion is to implement it using the best API that works, regardless of deprecation status. At the same time, implement a fallback method using command-line AppleScript. Test your installer with each and every macOS beta build. That's pretty much all you can do, isn't it?


          If all that falls apart in early June anyway, wrap your product inside an installer package that runs as root to begin with. Problem solved until 3rd party audio drivers get deprecated altogether.

          • Re: SMJobBless to sudo install HAL Plugin
            eskimo Apple Staff Apple Staff (11,225 points)

            I’m happy to answer all of your detailed questions but, before we go down that rabbit whole, I think we should talk about the big picture.  Ultimately what you’re building here is an installer.  There are three basic approaches you can use:

            • An installer package, to be installed by the Apple installer (A)

            • AuthorizationExecuteWithPrivileges (AEWP) (B)

            • The SMJobBless process, as illustrated by EvenBetterAuthorizationSample (EBAS) (C)

            You seem to have not considered A, which is a shame because IMO that’s the best option for you.  B and C both have problems, and I think it’s important that you understand those problems are before you pick an approach.

            The problem with B is that it’s deeply insecure.  Specifically, it’s highly vulnerable to impersonation: AEWP has no ability to determine whether the tool it runs is the tool that the user authorised to run.  This fundamental brokenness is the reason why AEWP was deprecated.

            The problem with C is that it’s complex.  When using C to implement an installer, you have to… well… implement an installer.  It’s a specialist installer, but it’s an installer nevertheless.

            The best way to think about this is that you’re not running a one-off installation, but installing an entire system for managing the installation of your product, now and in the future.  SMJobBless is used solely to bootstrap your privileges.  After that, you are responsible for how you use those privileges to achieve your installer’s goals (typically those would be install, upgrade, and uninstall).  The system provides all the infrastructure for doing this, you just have to write the code to use it properly.

            Ultimately this is a decision that you have to make, balancing a bunch of different requirements (time to write the code, desired UI, complexity, security, long-term compatibility, and so on).  Given your description of your requirements I think that approach A is the right one for you, but only you have all the information needed to make this choice.

            Share and Enjoy

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