Helper tool listed under developer's name in "System Settings > General > Login Items"

I’m developing an application, which requires execution of authorized privileged operations. Hence, the application needs to install its helper tool in /Library/PrivilegedHelperTools using SMJobBless() API and so on… The standard procedure, explained in numerous examples and sample codes on Apple Developer web site and elsewhere. This is not the first time I do that, so I did everything necessary to make it work. And it works perfectly; the helper tool is successfully verified and installed, privileged operations are successfully being executed upon authorization.

However, one thing bothers me and that is General > Login Items in the latest (and renamed) System Settings.app in Ventura. It allows user to manually enable/disable installed login items and helper tools (background items). My problem is that my helper tool appears in the list with my full name (Dragan Milic), probably extracted from the signing Developer ID Application: certificate, not with the name (and icon) of the application which verified/installed it. At the same time, some other items appear with the application name and icon. Please take a look at the attached picture below: I tried all I could think of to make the helper tool to appear with name/icon of the parent application, but without success. Using codesign and otool, I examined a bit some of the other applications and their helper tools, which correctly appear with application name/icon and I can't see much differences from my own, apart form different bundle identifiers and developer's signing certificates.

I'd be really, sincerely thankful if someone could help me solving this, as I've been banging my head agains it for more than a day. Thanks very much in advance.

-- Dragan

Up vote post of milke Down vote post of milke
2.4k views
Posted by
milke
Reply
Add a Comment

Accepted Reply

As an overall statement of intent, this UI is meant to show the name of the item’s responsible code, where responsible code is a term I defined in On File System Permissions. If it’s not doing that, that’s either a bug in your product or a bug in our operating system (-:

My problem is that my helper tool appears in the list with my full name … probably extracted from the signing Developer ID Application: certificate

That’s correct. This is one of the fallback paths that it’ll take if it can’t figure out the responsible code.

My understanding is that the system does not track the responsible code when you install via SMJobBless. That’s considered a legacy API, where the modern API is SMAppService. So, you have two choices:

  • Adopt SMAppService. This is clearly the best option (-:

  • If you can’t do that right now, the short-term solution is to add AssociatedBundleIdentifiers to your launchd property list. See the launchd.plist man page for details.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved

  • Should we expect SMAppService to work with privileged helper tools?

    —
    bombich
Add a Comment

Replies

Does the name Dragan Milic appear in your Info.plist file (the one for the main app, not the one for the helper)? I bet it's coming from there, not from the code signing information.

Posted by
JWWalker
Up vote reply of JWWalker Down vote reply of JWWalker
Add a Comment

As an overall statement of intent, this UI is meant to show the name of the item’s responsible code, where responsible code is a term I defined in On File System Permissions. If it’s not doing that, that’s either a bug in your product or a bug in our operating system (-:

My problem is that my helper tool appears in the list with my full name … probably extracted from the signing Developer ID Application: certificate

That’s correct. This is one of the fallback paths that it’ll take if it can’t figure out the responsible code.

My understanding is that the system does not track the responsible code when you install via SMJobBless. That’s considered a legacy API, where the modern API is SMAppService. So, you have two choices:

  • Adopt SMAppService. This is clearly the best option (-:

  • If you can’t do that right now, the short-term solution is to add AssociatedBundleIdentifiers to your launchd property list. See the launchd.plist man page for details.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved

  • Should we expect SMAppService to work with privileged helper tools?

    —
    bombich
Add a Comment

Thanks Quinn “The Eskimo!” 👍🏻

• Adopt SMAppService. This is clearly the best option (-:

I can't I still have to support macOS 10.13+

…the short-term solution is to add AssociatedBundleIdentifiers to your launchd property list. See the launchd.plist man page for details.

This is what I needed, it worked like a charm, thanks a lot!!

Now that I know the search keyword (AssociatedBundleIdentifiers), I see the solution already being discussed here. Unfortunately, changes in launchd.plist man page skipped my attention.

Thanks again,

-- Dragan

Posted by
milke
Up vote reply of milke Down vote reply of milke
Add a Comment