Issue with NSWorkspace openApplicationAtURL on Login Screen

Question

Created 3d

Replies 3

Boosts 0

Participants 2

When I tried to launch my application from non-gui process (from launch daemon) NSworkspace openApplicationAtURL failed if I tried to run it when my device on the login screen. Everything is working if someone logged in, but on the login screen I have the error

The application “TestApp” could not be launched because a miscellaneous error occurred. with code 256

    NSWorkspace* workspace = [NSWorkspace sharedWorkspace];
    NSWorkspaceOpenConfiguration* config = [NSWorkspaceOpenConfiguration configuration];
    config.createsNewApplicationInstance = YES;
    config.activates = NO;
    config.promptsUserIfNeeded = NO;
    config.addsToRecentItems = NO;

    [workspace openApplicationAtURL: appURL
          configuration: config
          completionHandler:^(NSRunningApplication *app, NSError *error)
          {

          }];

Sometimes after the third try it works, sometimes not at all. I try to use "open" command, it works on MacOS Sequoia, but not working for operating systems below, I see this error

The application cannot be opened for an unexpected reason, error=Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x600002998120 {Error Domain=OSLaunchdErrorDomain Code=125 "Domain does not support specified action" UserInfo={NSLocalizedFailureReason=Domain does not support specified action}}}

All these problems occur only on the login screen. I'm developing screen share utility, so I need somehow to launch my application on the login screen. Could someone please help me understand what is recommended way to launch application on the login screen?

Answered by DTS Engineer in 813811022

You are on the wrong path. If your program is a daemon:

It needs to be started by launchd, not by NSWorkspace.
It can’t be an app. Specifically, it mustn’t connect to the window server. See Technote 2083 Daemons and Agents for an in-depth explanation as to why not.

I'm developing screen share utility

What you need here is a pre-login agent. TN2083 talks about those, and there’s a (very old) sample: PreLoginAgents.

Creating a viable screen sharing product is tricky. It’s something I’ve discussed before a few times. Here’s some links to conversation you might find useful:

It’s likely that your product will need:

A container app, for interacting with the user
A launchd agent to capture the screen
A launchd daemon for managing the network connection

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

Boost

Answer 1

DTS Engineer OP

Apple

2d

Recommended

You are on the wrong path. If your program is a daemon:

It needs to be started by launchd, not by NSWorkspace.
It can’t be an app. Specifically, it mustn’t connect to the window server. See Technote 2083 Daemons and Agents for an in-depth explanation as to why not.

I'm developing screen share utility

What you need here is a pre-login agent. TN2083 talks about those, and there’s a (very old) sample: PreLoginAgents.

Creating a viable screen sharing product is tricky. It’s something I’ve discussed before a few times. Here’s some links to conversation you might find useful:

It’s likely that your product will need:

A container app, for interacting with the user
A launchd agent to capture the screen
A launchd daemon for managing the network connection

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

0

Answer 2

imdevv OP

1d

Thanks for the answer.

But for security reasons, my current architecture must be just one process for everything (capture, networking, etc). So right now my launch daemon just listening incoming connections, and after that just run a new process which do actual capture, networking and so on. The new process launches as current context - pre login or current console user, it depends on the current state.

Everything is working fine for older MacOS versions, but not for MacOS Sequoia. If I run a new process just using NSTask for example, everything is working except screen capture, so I assume that in the new MacOS version Apple wants to all capture process will start in different way.

I tried using NSWorkspace openApplicationAtURL, and sometimes it works on pre login context, but sometimes not.

So there is no other way to launch capture process except running it as launch agent? I can have several capture processes because for security reasons I need to have one connection - one process for that, and It should be completely isolated from different connection.

0

Answer 3

DTS Engineer OP

Apple

1d

So there is no other way to launch capture process except running it as launch agent?

The only supported way to do this is to use a launchd daemon to manage your networking and a launchd agent in each GUI login context to interact with the window server.

But for security reasons, my current architecture must be just one process for everything

What sort of threat does this protect against? That is, if you had multiple processes, what extra threats would you be vulnerable to?

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

0