You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Need the ability to pass a custom path with access permission to qemu via additional arguments.
Why
Currently, any qemu argument with a custom path will fail with error 'Operation not permitted'.
Although, applescript allows you to start a scoped access for a given path in an app's context, doing this in UTM app will not trickle down to qemu, because, qemu has its own app sandbox separate from UTM main app. (UTM qemu does not have its own scripting interface)
Example usage for custom path in qemu: Multiple Shared Directories
Users who need to share multiple directories via virtfs can do so if they pass multiple virtfs arguments by specifying path.
This works only if qemu can access the specified path.
Alternative: #5463 (reply in thread) - Currently users are resorting to making UTM create a sandbox permission for a given path through Shared Directory 'Browse..' option (The only way to open a path to sandbox) and then using it in the qemu argument. This could be made simpler.
Side Note:
Opening up qemu additional args via scripting have been very useful. eg:
launching vnc session via -vnc
Using UTM as a private cloud , by passing custom cloud-init files via -smbios to fire up UTM cloud images.
Share multiple directories ...
How
There are already functions in place to open a path to qemu via the "complicated sandbox dance" (Bookmark in UTM -> SecureScope in QEMUHelper (Also available to QEMULauncher) -> Store back the Bookmark in UTM for future use by QEMU ). we need to expose this to user in some form so users can pass their own path and use it with qemu.
There are two ways to expose :
Use existing files parameter in qemu additional arguments
In file urls user should pass the path used in the argument string. While updating the qemu config, UTM should open access to this path and store it. This allows the proper use of file with qemu.
Make a separate command to request sandbox permission
if the file urls in qemu args object is meant for something else, then we need a custom command in applescript for users to request permission.
The text was updated successfully, but these errors were encountered:
What
Need the ability to pass a custom path with access permission to qemu via additional arguments.
Why
Currently, any qemu argument with a custom path will fail with error 'Operation not permitted'.
Although, applescript allows you to start a scoped access for a given path in an app's context, doing this in UTM app will not trickle down to qemu, because, qemu has its own app sandbox separate from UTM main app. (UTM qemu does not have its own scripting interface)
Example usage for custom path in qemu: Multiple Shared Directories
Users who need to share multiple directories via virtfs can do so if they pass multiple virtfs arguments by specifying path.
This works only if qemu can access the specified path.
Alternative:
#5463 (reply in thread) - Currently users are resorting to making UTM create a sandbox permission for a given path through Shared Directory 'Browse..' option (The only way to open a path to sandbox) and then using it in the qemu argument. This could be made simpler.
Side Note:
Opening up qemu additional args via scripting have been very useful. eg:
-vnc
-smbios
to fire up UTM cloud images.How
There are already functions in place to open a path to qemu via the "complicated sandbox dance" (Bookmark in UTM -> SecureScope in QEMUHelper (Also available to QEMULauncher) -> Store back the Bookmark in UTM for future use by QEMU ). we need to expose this to user in some form so users can pass their own path and use it with qemu.
There are two ways to expose :
In file urls user should pass the path used in the argument string. While updating the qemu config, UTM should open access to this path and store it. This allows the proper use of file with qemu.
if the file urls in qemu args object is meant for something else, then we need a custom command in applescript for users to request permission.
The text was updated successfully, but these errors were encountered: