Draft: race free client identification

Introduces struct weston_client_app_info in the public API. It assumes a model where all clients which are not run in a flatpak sandbox can manipulate all other clients at will.

Clients are grouped into three categories: unknown, host/trusted base, flatpak. Unknown clients have no privileges (happens if the system can't identify clients at all or the original client process already died when the compositor tried to identify it), host/trusted base clients have all privileges and flatpak have either no or compositor defined privileges based on the app id.

The last commit shows how privileged protocols can be exposed to clients not started by the compositor but from the trusted base if the system supports SO_PEERPIDFD.

Marked as Draft because it depends on wayland patches and some kernel patches

kernel: https://github.com/swick/linux/tree/sopeerpidfd

testing: https://github.com/swick/peerpidfd

wayland: wayland!186

Also see: #206 (closed)

mentioned in merge request wayland!186

mentioned in merge request wayland-protocols!56 (closed)

What's your motivation for going this route instead of wayland-protocols!68 (merged)? I can only see drawbacks:

• It requires a new kernel API the kernel developers have been reluctant to provide (edit: and which wouldn't be portable to e.g. BSD, whereas whatever sandboxing system makes sense on BSD could definitely implement Simon's protocol).
• It appears to require specific knowledge of sandboxing mechanisms in the compositor. If I wanted to use VMs as sandboxes (a la Chrome OS, with Wayland over virtio-gpu), I'd have to separately teach Weston about that. With wayland-protocols!68 (merged), Flatpak and whatever else just need to implement a common protocol, and the compositor doesn't need to care about what specific sandboxing mechanism is in use.

Yeah, I also don't like any model where the compositor needs to add explicit support for individual sandboxing technologies…

The main benefit of this approach is that it requires no changes to the sandboxing mechanism, no new IPC and the changes to wayland/compositors are rather self-contained. The approach in wayland-protocols!68 (merged) is a lot more invasive and requires compositors to listen on multiple connection sockets and pipes to figure out when to close the socket.

The drawbacks you mention are real. I mostly wanted to show that this is feasible but if the other approach works better that would be great.

Another idea is to rely on the systemd desktop environment integration specification and read the cgroup which includes the launcher and ApplicationID. That would require the sandbox mechanisms to make sure the cgroup can't be messed with from inside. That would remove all sandbox mechanisms specific code from compositors but still require SO_PEERPIDFD and cgroups.

FYI the UAPI group is working on another SO_PEERPIDFD implementation in the kernel: https://lwn.net/ml/linux-kernel/20230522132439.634031-1-aleksandr.mikhalitsyn@canonical.com/