Here's a similar issue for MacOS:

• Ask for sudo/admin on files saving if required #13259

For reference, this sort of thing is generally accomplished in the following way on most Linux distributions (IE, using systemd/dbus/polkit)

• The application tries to perform a file operation, receives EPERM/EACCES
• The application sends a request to polkit containing subject (Information about the user performing the action and the calling process) and action¹ information (over dbus, which polkit bindings usually abstract for you)
• Polkit compares the subject/action against system policy and decides to either deny, allow, or require user intervention
• If polkit decides that user intervention is needed it creates a prompt using an appropriate polkit helper (Joey's screenshot above shows the GNOME-specific one which integrates with GNOME and looks native on that platform, Plasma users will see the Plasma dialog etc)
• Depending on what the user enters the "requires user intervention" will either evaluate to an allow or a deny
• If the action is "deny" the denial will be returned to the application
• If the action is "allow" then polkit will basically forward the subject/action over dbus to a dbus system service
• This dbus system service is typically start-on-demand, and the dbus service can only be connected to by root
• Dbus buffers the dbus call and starts the binary as specified in the dbus service file to handle it
• The binary processes the call and presumably does the encoded action as superuser, returning a reply to the calling application and exiting
• The calling application then processes the reply for whether it succeeded/failed and any necessary context information and then updates the UI accordingly

So from the perspective of Zed, what needs to be changed to handle this is the following:

• Create a new libexec helper binary (note that technically these dbus interfaces could be implemented into the zed-editor libexec binary but for latency and security reasons creating a highly minimal separate binary is a better option).
• Create dbus service files that basically state that the dbus service is ran as root and that only root can own the interface (IE only root processes can connect to it over dbus)
• Create a polkit policy document
• Implement a wrapper around file writing operations on Linux that catches EPERM/EACCES and handles the appropriate polkit action.
• Try to engage with the SUSE security team to review the design of all of this since they have numerous experts and tend to be responsive to open source projects

References:

• https://venam.net/blog/unix/2020/07/06/dbus-polkit.html
• https://security.opensuse.org/2024/04/02/kde6-dbus-polkit.html

And this is how it's implemented in Kate:

• https://invent.kde.org/frameworks/ktexteditor/-/blob/v6.3.0/src/buffer/katesecuretextbuffer.cpp
• https://invent.kde.org/frameworks/kauth/-/blob/master/src/backends/polkit-1/Polkit1Backend.cpp?ref_type=heads