ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
karenw has quit [Ping timeout: 480 seconds]
<danieldg>
huh, I didn't notice that way-secure actually got harder to use since I last updated it
glennk has quit [Ping timeout: 480 seconds]
ybogdano has joined #wayland
iomari891 has joined #wayland
feaneron has joined #wayland
Moprius has joined #wayland
Moprius has quit [Quit: bye]
kts has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
tlwoerner has joined #wayland
Orko|blinkOn[m] has joined #wayland
iomari891 has quit [Read error: Connection reset by peer]
feaneron has quit [Ping timeout: 480 seconds]
garnacho has joined #wayland
sima has joined #wayland
tzimmermann has joined #wayland
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
glennk has joined #wayland
leon-anavi has joined #wayland
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
Tom^ has joined #wayland
<pq>
orowith2os[m], libwayland-server is fundamentally *not* thread-safe at all.
psykose has quit [Remote host closed the connection]
psykose has joined #wayland
kts has joined #wayland
mripard has joined #wayland
nerdopolis has joined #wayland
Moprius has quit [Quit: bye]
nerdopolis_ has joined #wayland
nerdopolis is now known as Guest13079
nerdopolis_ is now known as nerdopolis
Guest13079 has quit [Ping timeout: 480 seconds]
feaneron has quit [Ping timeout: 480 seconds]
<WhyNotHugo>
vyivel: how would you use a tool with the design that you mention? Using WAYLAND_SOCKET instead of WAYLAND_DISPLAY?
<WhyNotHugo>
danieldg: not sure how to make this simpler; feedback welcome :)
<vyivel>
WhyNotHugo: probably, wlsecctx seems to use WAYLAND_DISPLAY
<vyivel>
my use case is to run exactly one client per socket anyway
<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.
kts has quit [Ping timeout: 480 seconds]
feaneron has joined #wayland
<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.
iomari891 has quit [Read error: No route to host]
<danieldg>
I'd say supporting both creating and passing in the socket is better, if increased flexibility there is useful
<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
Brainium has joined #wayland
kts has joined #wayland
tzimmermann has quit [Quit: Leaving]
kts has quit [Quit: Konversation terminated!]
leon-anavi has quit [Quit: Leaving]
coldfeet has joined #wayland
mripard_ has joined #wayland
paulk has joined #wayland
mripard has quit [Ping timeout: 480 seconds]
paulk-ter has quit [Read error: Connection reset by peer]
mripard has joined #wayland
mripard_ has quit [Ping timeout: 480 seconds]
___nick___ has joined #wayland
akimoto has joined #wayland
kasper93 has quit [Quit: kasper93]
kasper93 has joined #wayland
akimoto has quit [Remote host closed the connection]
___nick___ has quit []
<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)
<WhyNotHugo>
what do you mean by "having to create the socket yourself is harder"?
___nick___ has joined #wayland
<WhyNotHugo>
there's an example of how to bind the socket to the filesystem do so in the README, it's just one command
___nick___ has quit []
sima has quit [Remote host closed the connection]
___nick___ has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
<riteo>
Hi people, I'm hooking up FIFO support for Godot as we're currently manually pacing frames ourselves
<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?
kasper93 has quit [Quit: kasper93]
kasper93 has joined #wayland
rasterman has joined #wayland
tanty has quit [Quit: Ciao!]
tanty has joined #wayland
coldfeet has quit [Quit: Lost terminal]
tanty has quit [Quit: Ciao!]
tanty has joined #wayland
f_ is now known as funderscore
___nick___ has quit [Remote host closed the connection]
tanty has quit [Quit: Ciao!]
tanty has joined #wayland
tanty has quit [Quit: Ciao!]
tanty has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
feaneron has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
Calandracas has quit [Ping timeout: 480 seconds]
Calandracas has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
<danieldg>
WhyNotHugo: a dependency on socketbinder is harder than not having a dependency
<danieldg>
the initial version (that I never updated from) did not depend on that
<danieldg>
it's not hard, sure, but it's an extra step
<danieldg>
anyway, I'm not trying to get you to change it, especially for systemd, just sharing how I use it
<WhyNotHugo>
danieldg: i think you can also use socat, right? i only now realise that a sh can't pipe this in any way
<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?
<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.
<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
<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
<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
<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
<danieldg>
this is during sandbox setup; nothing malicious is in there yet
<danieldg>
also you can't grab a socket fd via /proc/*/fd/*
<danieldg>
at least, a connected one
<danieldg>
maybe you could connect() to one, but you can't open() a socket
<WhyNotHugo>
way-secure can linger beyond setup. it still feels wrong to move the priviledged fd into the sandbox, even if during setup
<danieldg>
well, you'd make sure not to use a lingering mode to do this
<danieldg>
you could have way-secure close its wayland fd before lingering if you like
<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