00:32 danieldg: huh, I didn't notice that way-secure actually got harder to use since I last updated it
07:40 pq: orowith2os[m], libwayland-server is fundamentally *not* thread-safe at all.
09:03 wlb: weston/main: Pekka Paalanen * 8 commits https://gitlab.freedesktop.org/wayland/weston/compare/1030268c6df55df72942bf607cd0882e3704145c...cb43a086b5603614e9699187c362f8fab95a6da3
09:03 wlb: weston Merge request !1718 merged \o/ (color: trivialities, refactoring https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1718)
11:33 wlb: wayland Merge request !467 opened by Carlos Garnacho (carlosg) protocol: Make pointer cursor updates responsibility of compositors https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/467
13:23 WhyNotHugo: vyivel: how would you use a tool with the design that you mention? Using WAYLAND_SOCKET instead of WAYLAND_DISPLAY?
13:24 WhyNotHugo: danieldg: not sure how to make this simpler; feedback welcome :)
13:24 vyivel: WhyNotHugo: probably, wlsecctx seems to use WAYLAND_DISPLAY
13:26 vyivel: my use case is to run exactly one client per socket anyway
13:26 WhyNotHugo: vyivel: i see that i creates a directory with a socket. You need to ensure that your client has access to the socket under the same path.
13:56 danieldg: WhyNotHugo: imo having to create the socket yourself is harder than specifying the path. I also locally modified it to support throwing alive_fd at systemd instead of parking the process, but that might not be useful in general.
13:58 danieldg: I'd say supporting both creating and passing in the socket is better, if increased flexibility there is useful
14:01 danieldg: and by 'throw' I mean 'use the FDSTORE=1 notify message' so that a unit with Type=oneshot FileDescriptorStoreMax=1 FileDescriptorStorePreserve=yes holds on to it
18:05 WhyNotHugo: danieldg: the current implementation can use any fd-holder. hardcoding it to use systemd would make the implementation non-portable (I don't use it on any hosts with systemd)
18:06 WhyNotHugo: what do you mean by "having to create the socket yourself is harder"?
18:06 WhyNotHugo: there's an example of how to bind the socket to the filesystem do so in the README, it's just one command
18:33 riteo: Hi people, I'm hooking up FIFO support for Godot as we're currently manually pacing frames ourselves
18:34 riteo: Am I correct by saying that mesa currently only implements it for the Vulkan WSI and not for EGL? Is there a way to detect whether we can trust the compositor to have a forward-progressing implementation, or should I just assume that fifo-v1 -> a working vulkan FIFO?
23:13 danieldg: WhyNotHugo: a dependency on socketbinder is harder than not having a dependency
23:13 danieldg: the initial version (that I never updated from) did not depend on that
23:14 danieldg: it's not hard, sure, but it's an extra step
23:16 danieldg: anyway, I'm not trying to get you to change it, especially for systemd, just sharing how I use it
23:17 WhyNotHugo: danieldg: i think you can also use socat, right? i only now realise that a sh can't pipe this in any way
23:18 WhyNotHugo: this still creates the socket in the same mount namespace as the "real" compositor tho. don't you need something to bind it inside your sandbox?
23:20 danieldg: you can drop the socket in a location that is visible both inside and out. I agree passing the fd in is useful at times, just not every time.
23:20 danieldg: I don't know that you can use socat to hand off the listening fd - iirc it hands out the connected fds - but maybe there's an option I missed
23:22 danieldg: I have used the "put a helper inside the sandbox namespace and export a bound fd" before, but that has to be done over a unix socket of some type instead of by fd to child
23:25 danieldg: having a helper prepare a WAYLAND_SOCKET environment variable and running way-secure inside the sandbox is another good alternative, and one that uses the socket by path
23:26 danieldg: conn-to-wayand enter-sandbox --the-blue-one way-secure --socket-path ...
23:30 WhyNotHugo: danieldg: i wouldn't run way-secure inside the sandbox; you're giving the sandbox access to an fd to the priviledged socket. /proc/_/fd leaks it
23:30 danieldg: this is during sandbox setup; nothing malicious is in there yet
23:31 danieldg: also you can't grab a socket fd via /proc/*/fd/*
23:31 danieldg: at least, a connected one
23:31 danieldg: maybe you could connect() to one, but you can't open() a socket
23:31 WhyNotHugo: way-secure can linger beyond setup. it still feels wrong to move the priviledged fd into the sandbox, even if during setup
23:31 danieldg: well, you'd make sure not to use a lingering mode to do this
23:32 danieldg: you could have way-secure close its wayland fd before lingering if you like
23:34 danieldg: given the way container sandboxes work, exporting the listening fd from the sandbox is more effort than carrying one with you as you enter
23:42 WhyNotHugo: danieldg: https://git.sr.ht/~whynothugo/way-secure/commit/470721e3246264d94c9f23e069167befabe7c613
23:43 WhyNotHugo: danieldg: i would (1) create an unpriviledged socket (2) enter sandbox (3) bind socket in the right place
23:43 WhyNotHugo: i need to bind other sockets too anyway
23:47 danieldg: hmm, I guess I didn't think of forking while holding an unbound socket; that would work nicely too
23:48 danieldg: funnily enough rust doesn't really support that, as bind is the constructor
23:49 danieldg: (iirc you can do it in rust with one of the other crates, just not with std itself)