Comment by nine_k

Comment by nine_k a day ago

4 replies

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.)

Arnavion a day ago

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.

  • Cloudef 14 hours ago

    Hyprland has sort of permission handling https://wiki.hypr.land/Configuring/Permissions/ But yeah there isn't really a "standard wayland ecosystem way"

    • Arnavion 10 hours ago

      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?