Re: Problem with NSWorkspace.shared and uid 0
Re: Problem with NSWorkspace.shared and uid 0
- Subject: Re: Problem with NSWorkspace.shared and uid 0
- From: Jean-Daniel <email@hidden>
- Date: Fri, 15 Dec 2017 18:05:51 +0100
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 <email@hidden> 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 (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden