02:15smallville7123: welp i got a little more stuff to compile
02:16smallville7123: still gotta fix a ton of errors and warnings ;-;
04:49smallville7123: what syscalls does wayland use for signals ?
04:52smallville7123: hmm apparently it uses the kill syscall (from event-loop-tests.c)
05:09smallville7123: it appears that PostgreSQL has ported the signal and shm system to windows o.o
05:09smallville7123: how well such works i dont know
05:18smallville7123: tho... does the wayland event loop only ever catch SIGUSR1 or can it catch any other signal that can be caught with sigprogmask?
05:21smallville7123: ill see how cygwin goes about signals
06:18idkrn[m]: Anyone know if the xhost tool mentioned in https://wiki.gentoo.org/wiki/Simple_sandbox has a Wayland alternative?
16:37tleydxdy: I think you can just give the user rw access to the wayland socket
17:36idkrn[m]: <tleydxdy> "I think you can just give the..." <- How? I added them to the video group but I'm pretty sure that is useless
18:44i509VCB: From the discussion about a wayland 2.0 adding 64-bit wire types, couldn't compatibility with 1.0 be done by lowering the 2.0 wire types to 1.0 wire types?
18:45i509VCB: Then wayland-scanner or the wayland-rs scanner or etc could expose the 64-bit types in the generated protocol bindings
18:58kennylevinsen: if something needs 64-bit it could just be sent as 2 32-bit ints - I think that's the least of the Wayland 2.0 concerns
20:02daniels: idkrn[m]: socket access is all you need - either set permissions so you can access it, or as Flatpak does, bind-mount the socket into the sandbox
21:39idkrn[m]: <daniels> "idkrn: socket access is all..." <- So bubblewrap works for it?
21:40idkrn[m]: Set the permissions with what? Chmod?
21:44idkrn[m]: I'm pretty sure you don't mean chmod
21:44mjt: that's a difficult situation indeed.. if there's no other tool to set permissions, maybe such a tool should be written quickly
21:44mjt: </sarcasm>
21:45mjt: it is a socket file. that whole path needs to be accessible
21:46mjt: usually /run/user/$UID/wayland-0
21:47daniels: mjt: the sarcasm is pretty unnecessary tbh
21:48mjt: it's sometimes difficult to resist :)
21:48idkrn[m]: Yeah but it was a dumb question
21:48daniels: idkrn[m]: indeed, Wayland itself doesn't enforce any extra checks on clients connecting to the socket. if the socket is accessible to the client (through permissions indeed), then it can speak to the server. if it isn't accessible, then you can make it accessible with permissions or ACLs. if it isn't visible in the path (e.g. chroot), then you can make it visible via a bind mount
21:48idkrn[m]: daniels: It only needs to be visible?
21:49daniels: idkrn[m]: visible (by path), and accessible (by permissions). if you have both of those things, then you're in, without anything extra like xhost
21:49daniels: (bwrap uses bind mounts to do this)
21:50idkrn[m]: daniels: Ok thanks
21:50daniels: np :)
21:50idkrn[m]: daniels: How do I let it use my Wayland socket when it's under a different UID
21:50mjt: I guess it's easiest to bind-mount it (which might require root)
21:51daniels: idkrn[m]: same answer - either bind-mount it in, or open the permissions out
21:51idkrn[m]: daniels: So if I wanted to automate this for multiple applications, bubblewrap would he simplest?
21:51idkrn[m]: Or just set the perms to 444
21:52kennylevinsen: setfacl might do the trick
21:52daniels: yeah, either setfacl to grant to individual UIDs, or if you're trying to start each app in an isolated UID (namespace), then I'd probably just use bwrap to begin with
21:52mjt:just googled for "wayland as different user" -- as usual, the solution suggested is to chmod 0777 /run/user/$UID. Looks like this 777 will never die.. :( (don't do that)
21:53idkrn[m]: Ok thanks everyone
21:53daniels: np
21:53idkrn[m]: <daniels> "mjt: the sarcasm is pretty..." <- Even for mjt :)
21:53idkrn[m]: mjt: Seems like a bad idea lmao
21:54daniels: idkrn[m]: we've all asked seemingly-dumb questions at one point in time, it's all good
21:54idkrn[m]: stat /run/user/$UID/wayland-* gives 755 though
21:54mjt: it is the directory which is restricted
21:54idkrn[m]: mjt: Good to know
21:54mjt: sockets ignore permissions, fwiw
21:55idkrn[m]: Yes it seems to be 700
21:55mjt: hmm. I'm not actually sure for sockets anymore, it was system-dependent, don't remember how it is on linux these days...
21:56mjt: but either way it doesn't matter in this case
21:56idkrn[m]: idkrn[m]: The directory I mean
22:01mjt: touch /run/user/$UID2/wayland-0; mount --bind /run/user/$UID/wayland-0 /run/user/$UID2/wayland-0 -- this gives user with UID2 access to wayland socket of user with UID
22:22idkrn[m]: Hmmm
22:22idkrn[m]: I can sudo -u … bash
22:23idkrn[m]: Still can't get my program to work…
22:25idkrn[m]: I think maybe I could put up a pastebin of what I've done for people that have enough time to help
22:30mjt: what are you trying to do anyway?