AFAIK, this is not an issue with uid 0 specifically, but more an issue with how LaunchService works (the framework underlying this part of NSWorkspace).
The system maintains a per user databases of the installed bundles. This databases is updated each time an user interact with a new application, mount a drive, etc. As the user 0 is not a legit interactive user, it’s LaunchService database lacks a lots of informations. This design make sens as it is perfectly fine for an user to install a bundle into its home directory and it should be the only one to see it. As Jens said, AppKit (and LaunchService) are not design to be used by a uid 0 daemon and should instead only be used by user agents running on each active session (which can then report the result to a uid 0 daemon). > Le 13 déc. 2017 à 04:14, sqwarqDev <sqwarq...@icloud.com> a écrit : > > When using the absolutePathForApplication(withBundleIdentifier:) api, I find > that if the path is on an external mount, the api will return nil / none if > the uid is 0, when it will return an actual path when the uid is a valid user > login id (eg, 501, 502 etc). > > To reproduce, mount a .dmg containing some app that isn’t on the boot drive, > and insert its bundeID for the value of inputPath in the code below: > > > import Foundation > import AppKit > > let inputPath = “com.some.bundleID" > let pathToApp: String? = > NSWorkspace.shared.absolutePathForApplication(withBundleIdentifier: inputPath) > let result = pathToApp ?? "nil" > print(result) > > > In Xcode, if I edit the scheme to debug/run as myself, I’ll get a valid > result, but if I edit it to run as root, I’ll get back this error msg: > > schedule invalidation <DYTransport 0x10128bcc0, error: lost transport > connection (31)> > > I have also tried querying LaunchServices directly with > > let altPath = LSCopyApplicationURLsForBundleIdentifier(inputPath as CFString, > &error) > > which again returns successfully as me, but as root gives the error: > > Error Domain=NSOSStatusErrorDomain Code=-10814 "kLSApplicationNotFoundErr: > E.g. no application claims the file”)) > > It’s been suggested to me that the problem may be that the LS database isn’t > updated for transient mounts for the root user. That makes sense of the error > messages, but two questions: > > 1. Should this be considered a bug, or expected behaviour? > 2. Any suggestions for a workaround? > > > TIA > > > > Best > > > Phil > @sqwarq > > > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/mailing%40xenonium.com > > This email sent to mail...@xenonium.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
