On macOS, briefcase run requires admin status

[rmartin16]

Describe the bug

briefcase run can fail for users with limited access. For instance, this macbook is remotely managed and limits administrative tasks by default.

❯ briefcase run --log

[helloworld] Building App...
Renaming stub binary... done

[helloworld] Ad-hoc signing app...
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100.0% • 00:02

[helloworld] Built build/helloworld/macos/app/Hello World.app

[helloworld] Starting app...
===========================================================================
log: Must be admin to run 'stream' command

Steps to reproduce

Not specifically sure...but run briefcase run for a limited user on macOS.

Expected behavior

The app could run without log stream perhaps.

Screenshots

No response

Environment

• Operating System: Sequoia
• Python version: 3.12.7
• Software versions:
  • Briefcase: 0.3.20.dev369+gf6b5d83f

Logs

briefcase.2024_12_15-11_13_36.run.log

Additional context

No response

[freakboy3742]

Well... that's going to be a right pain. "Don't stream the logs" is going to be a really suboptimal solution, because you won't see any stdout/stderr output of the app.

Are you able to see the logs when you run in Xcode? It seems highly unlikely that macOS would prevent any non-admin user from being able to view logs. I wonder if a different predicate (something based on the PID perhaps?) would avoid triggering permission issues?

[mhsmith]

According to man log:

By default, the command assumes system-wide streaming. Specifying a process id with the --process option will narrow the results.

I wonder if this might also help with our chronic "Messages dropped during live streaming" problem on iOS and macOS.

[freakboy3742]

I wonder if this might also help with our chronic "Messages dropped during live streaming" problem on iOS and macOS.

That's an interesting thought - sounds like it would definitely worth investigating to see if PID-based filtering gets around the admin-user requirement.

The one other complication is that the current setup involves starting the log, then starting the app, which guarantees that you get all the logs. However, to filter logs based on PID, we'd need to start the app, then the logs, which would potentially leave a small window at the start of execution where a log wasn't available.

In the macOS case, the other option that might be worth pursuing is the --stdout and --stderr arguments to open. Those arguments allow streaming stdout and stderr to a file, which we could then stream. I haven't played with those options extensively, but if "Briefcase debug" mode disabled log redirection, that might provide an alternate way to display logs.