fix(macOS): Tauri Update Permission Denied Error

[jLynx]

• Addressed the problem of Tauri updater failing for standard (non-admin) users on macOS with a "Permission Denied" error as stated in this issue [bug] [macOs] Tauri updater fails with "Tauri API error: Permission Denied (os error 13)" for standard (non-admin) users #8104.
• Modified the copy_files_and_run function for macOS to handle permission issues more gracefully.
• Introduced an AppleScript-based solution to request administrator privileges when needed:
  • If a permission error is detected, the script prompts for admin credentials.
  • Uses osascript to execute shell commands with elevated privileges.
• Added a helper function is_permission_error to identify permission-related errors.
• Ensured that the solution works for both standard and admin users, providing a more robust update mechanism.

Credit to @0rvar as this code is from them

[github-actions]

Package Changes Through 691bace

There are 9 changes which include tauri with patch, tauri-codegen with patch, tauri-cli with patch, @tauri-apps/cli with patch, tauri-bundler with patch, tauri-utils with patch, tauri-build with patch, tauri-runtime with patch, tauri-runtime-wry with patch

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
tauri-utils	1.6.0	1.6.1
tauri-bundler	1.6.0	1.6.1
tauri-runtime	0.14.4	0.14.5
tauri-runtime-wry	0.14.9	0.14.10
tauri-codegen	1.4.4	1.4.5
tauri-macros	1.4.5	1.4.6
tauri-build	1.5.3	1.5.4
tauri	1.7.1	1.7.2
@tauri-apps/cli	1.6.0	1.6.1
tauri-cli	1.6.0	1.6.1

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[jLynx]

Hey team!
Just wondering what the PR cycle time & release timeline for Tauri? Just wondering on average how long this will be before it goes into prod

[tweidinger]

Timelines and review times are very much flexible and depend on people/code owners/working group members available.

The initial review showed some potential issues with TOCTU (Time of Check Time of Use) attacks (old reference) and I am still not sure if we are fine to accept the potential risk in this specific case.

Currently we do a signature validation in memory and not write to disk to prevent such TOCTU attacks, which has its issues and one of them caused this PR. With writing to the temp folder we open up to other processes of the system and just replacing the files in temp folder would allow another unprivileged application to gain admin rights in the worst case.

The solution here does use a library which limits the umask to the current user by default, so no direct risk from other users but only other processes from the same user. The elevation is only used for moving files, so no risk of direct execution. The only direct risk would be other processes are able to manipulate the Tauri app or replace it with their own binary. This can have impact depending on how your system or organization is set up and how much untrusted binaries are running on your system 😀.

I'll discuss once more with @chippers and maybe @lucasfernog on what we think about this and if there are changes needed but can't give you a specific timeline.

[jLynx]

I appreciate the feedback & update @tweidinger