Comment by nine_k
20 hours ago
It's almost as if a Wayland compositor should keep a list of trusted apps to broadcast clipboard events to, somehow similar to how screenshots are handled. (Not that Wayland is well-rounded in this regard.)
20 hours ago
It's almost as if a Wayland compositor should keep a list of trusted apps to broadcast clipboard events to, somehow similar to how screenshots are handled. (Not that Wayland is well-rounded in this regard.)
The ext_data_control_v1 protocol I mentioned is a protocol specifically for clipboard managers. So a client that wants to be a clipboard manager would implement that protocol. There are already implementations of it like wl-clipboard. There is no need for the compositor to broadcast regular clipboard events (wl_data_offer).
Now the compositor could certainly keep an additional list of trusted applications that are allowed to be clients of the ext_data_control_v1 protocol. Though identifying the client to enforce such a thing is a bigger problem than just maintaining a list of applications, because the protocol has no client identification. AFAIK every compositor that supports that protocol has no restrictions on clients requesting it, though something involving the security-context protocol might change this in the future.
Hyprland has sort of permission handling https://wiki.hypr.land/Configuring/Permissions/ But yeah there isn't really a "standard wayland ecosystem way"
I see the prompt-less permission config is based on the executable path. How does it get the executable path for the client? And is it robust against me spinning up a mount namespace with an arbitrary /usr/bin/grim that I control?