ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
jmdaemon has joined #wayland
ybogdano has quit [Ping timeout: 480 seconds]
mtj has quit [Server closed connection]
mtj has joined #wayland
Net147 has quit [Server closed connection]
Net147 has joined #wayland
jbit has quit [Server closed connection]
jbit has joined #wayland
_whitelogger has joined #wayland
riverdc has quit [Server closed connection]
riverdc has joined #wayland
JPEW has quit [Server closed connection]
JPEW has joined #wayland
ManMower has quit [Server closed connection]
ManMower has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
xyene has quit [Server closed connection]
xyene has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
fmuellner has quit [Remote host closed the connection]
smallville7123 has quit [Server closed connection]
smallville7123 has joined #wayland
Shimmy04003 has joined #wayland
Shimmy0400 has quit [Ping timeout: 480 seconds]
ecs_ has quit [Server closed connection]
ecs has joined #wayland
rektide has quit [Server closed connection]
rektide has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
isinyaaa has quit [Server closed connection]
isinyaaa has joined #wayland
caseif has quit [Server closed connection]
caseif has joined #wayland
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
danshick_ has quit [Server closed connection]
danshick has joined #wayland
abdur has quit [Server closed connection]
abdur has joined #wayland
seanpaul_ has quit [Server closed connection]
seanpaul_ has joined #wayland
tkna has quit [Server closed connection]
tkna has joined #wayland
lvrp16 has quit [Server closed connection]
lvrp16 has joined #wayland
zebrag has joined #wayland
yongxiang______ has quit [Server closed connection]
yongxiang______ has joined #wayland
hwentlan_ has quit [Server closed connection]
hwentlan_ has joined #wayland
Company has quit [Quit: Leaving]
jimjams has quit [Server closed connection]
jimjams has joined #wayland
<smallville7123>
what is wl_os_socket_peercred used for?
gildekel has quit [Server closed connection]
gildekel has joined #wayland
pieguy128 has quit [Server closed connection]
pieguy128 has joined #wayland
jlco has quit [Server closed connection]
jlco has joined #wayland
ebassi has quit [Server closed connection]
ebassi has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
jgrulich has joined #wayland
tzimmermann has joined #wayland
bodiccea has quit [Server closed connection]
bodiccea has joined #wayland
Sachiel has quit [Server closed connection]
Sachiel has joined #wayland
kasper93 has quit [Server closed connection]
kasper93 has joined #wayland
hardening has joined #wayland
hendry has joined #wayland
gspbirel568 has quit [Server closed connection]
gspbirel568 has joined #wayland
kts has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
jgrulich has quit [Quit: Konversation terminated!]
jgrulich has joined #wayland
jgrulich has quit [Quit: Konversation terminated!]
jgrulich has joined #wayland
pH5 has quit [Server closed connection]
pH5 has joined #wayland
danvet has joined #wayland
mvlad has joined #wayland
MrCooper has quit [Server closed connection]
MrCooper has joined #wayland
daniels has quit [Server closed connection]
daniels has joined #wayland
manuel1985 has joined #wayland
tlwoerner has quit [Server closed connection]
tlwoerner has joined #wayland
yar has quit [Server closed connection]
yar has joined #wayland
d10n has quit [Server closed connection]
d10n has joined #wayland
tanty has quit [Remote host closed the connection]
pbsds0 has quit [Server closed connection]
pbsds0 has joined #wayland
tanty has joined #wayland
MajorBiscuit has joined #wayland
BPCZ has quit [Server closed connection]
BPCZ has joined #wayland
bindu has quit [Server closed connection]
Satan has quit [Server closed connection]
bindu has joined #wayland
Satan has joined #wayland
anarsoul has quit [Server closed connection]
anarsoul has joined #wayland
benbrown has quit [Server closed connection]
benbrown has joined #wayland
dcz_ has joined #wayland
rasterman has joined #wayland
cnsvc has quit [Server closed connection]
cnsvc has joined #wayland
FLHerne has quit [Server closed connection]
FLHerne has joined #wayland
aswar002 has quit [Server closed connection]
aswar002 has joined #wayland
coleman has quit [Server closed connection]
coleman has joined #wayland
everfree has quit [Server closed connection]
everfree has joined #wayland
genpaku has quit [Server closed connection]
genpaku has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
<smallville7123>
welp, now i gotta figure out how to get `wl_os_recvmsg_cloexec`, `wl_connection_read`, `build_cmsg`, and `ring_buffer_put_iov` implemented in windows WinSocks
<pq>
Does Windows have the concept of sending file descriptors over a local socket?
<pq>
That cmsg stuff is magic, it's not simply sending integers because they are file descriptors.
<smallville7123>
dunno
<kennylevinsen>
only way I know is to DuplicateHandle into the other process, and then send the handle as an integer
<kennylevinsen>
But I don't remember if that requires elevated privileges
<pq>
ok, so it's doable, but not in the way libwayland does it
* kennylevinsen
tries to suppress the memories of of dealing with this
<pq>
for that, you'd need to modify the marshall/unmarshall code to actually send the integer while replacing the cmsg magic with that DuplicateHandle magic.
<pq>
iov OTOH is easy to work around if you don't have it, just make another copy of the pieces of data into a single contiguous buffer.
<kennylevinsen>
on linux you can obtain the PID of the other side using peercred, maybe something similar is available for windows
<smallville7123>
eg, server -> PID -> client dup_handle(self_pid, handle, out_handle, PID, ...) client -> OUT_HANDLE -> server
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
peeterm has quit [Ping timeout: 480 seconds]
peeterm has joined #wayland
SardemFF7 has quit [Server closed connection]
SardemFF7 has joined #wayland
agd5f has quit [Server closed connection]
agd5f has joined #wayland
junaid has quit [Ping timeout: 480 seconds]
markbolhuis has joined #wayland
<smallville7123>
pq: ok, so... the server creates a named socket, the client connects to this socket
Leopold_ has joined #wayland
<pq>
yup
Sumera[m] has quit [Server closed connection]
Sumera[m] has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
Leopold_ has quit []
Leopold has joined #wayland
<smallville7123>
then it appears that it uses wl_proxy_marshal and related api's to marshal fd's across the server/client
<smallville7123>
even though it has "\note This should not normally be used by non-generated code."
<smallville7123>
for all proxy_marshal functions
<pq>
genrated code refers to wayland-scanner output
<smallville7123>
oh ok
<smallville7123>
so in otherwords, it should not be used by code generated by wayland-scanner ?
<pq>
wayland-scanner takes the XML, and generated a C API for it which is implemented in terms of those low-level functions people are not supposed to use directly.
<pq>
anyone can write their own XML files, generated the C API for it, and then just have libwayland shovel those messages around without needing to change libwayland at all
Leopold has quit []
<kennylevinsen>
"this should not normally be used by non-generated code" -> it should normally *only* be used by code generated by wayland-scanner
<kennylevinsen>
double negatives...
Leopold has joined #wayland
<pq>
heh
<smallville7123>
:)
<smallville7123>
so what actually sends the descriptors to and from the server/client ?
<pq>
it's that cmsg magic you saw
<pq>
SCM_RIGHTS
<smallville7123>
yes, but like, from a client/server implementation perspective
<kennylevinsen>
generated API that takes an FD as argument -> fds gets put in the fd part of the connection ring buffers -> fd get included in cmsg
<smallville7123>
what would that be?
<kennylevinsen>
what would what be
<pq>
an fd in C is just an int with a special meaning
<smallville7123>
what do the cpu/gpu buffer functions call to pass the fd to the ringbuffer?
Leopold has quit [Remote host closed the connection]
<kennylevinsen>
wl_closure_queue/wl_closure_send is used for all sending. That calls copy_fds_to_connection, which finds all fds in that closure and puts them in the "outgoing fds" ring using wl_connection_put_fd
<kennylevinsen>
you'd benefit from reading the file I sent
ofourdan has quit [Ping timeout: 480 seconds]
<smallville7123>
yea
<smallville7123>
seems both invoke copy_fds_to_connection
<smallville7123>
tho i cant seem to find where the size of the fd is counted in the get closure size
<kennylevinsen>
not sure what you mean by closure size, but note that the fds being sent are auxillary data, and not part of the main data being sent
<smallville7123>
this buffer_size_for_closure
<smallville7123>
hmm
Lucretia has quit [Remote host closed the connection]
<smallville7123>
so if copy_fds_to_connection copies the fd's to the ring buffer, when does the ring buffer get used
<kennylevinsen>
they're copied to the fd ring buffer
<kennylevinsen>
not the main ring buffer
MajorBiscuit has quit [Ping timeout: 480 seconds]
<smallville7123>
so, in wl_connection_write, if there are fd's in the fd buffer, it calls wl_connection_flush, and then when those are sent, it calls ring_buffer_put ?
Lucretia has joined #wayland
<smallville7123>
eg, if we want to send 2 fd's, then wl_closure_send -> wl_connection_write -> wl_connection_flush, wl_closure_send -> wl_connection_write -> wl_connection_flush, then it sends whatever is left in the data buffer
<smallville7123>
?
<kennylevinsen>
wl_connection_flush sends what is in the ring buffers
<kennylevinsen>
(which involves both the data buffer and fd buffer)
haasn has quit [Server closed connection]
haasn has joined #wayland
<kennylevinsen>
flush is rarely called, usually by wl_display_dispatch at the end of your event loop to send everything
<smallville7123>
alright
<kennylevinsen>
one wl_closure_send can contain multiple fds, so it depends onw hether it's 1 message with 2 fds or 2 messages with 1 fd each
<kennylevinsen>
1 message with 2 fds is just 1 call to wl_closure_send
<smallville7123>
for ring_buffer_get_iov, does an existing iov need to exist in the ring buffer?
<kennylevinsen>
the ring buffer is just bytes, not iovs
<smallville7123>
alright
<kennylevinsen>
if you read wl_connection_flush, you'd see that iov's end up passed to sendmsg, so look at the manpage for sendmsg
<smallville7123>
hmmm
<smallville7123>
in linux, the fd DOES NOT need to be duplicated in order to be sent to another process, right?
<kennylevinsen>
when you send an fd, a new fd is created in the receiving process. Exactly the same as under Windows.
<kennylevinsen>
(with DuplicateHandle that is)
<kennylevinsen>
dup'ing the fd first just adds more fds in the sender process, so that would be useless
<kennylevinsen>
(you can't "move" an fd - the holder still has the original, the recipient has a copy)
<smallville7123>
hmm ok
devilhorns has quit [Ping timeout: 480 seconds]
<smallville7123>
to send such in windows, we must first dup the fd and then send the dupped fd value to the recipient to open
<smallville7123>
which means we first need the recipient's pid
<pq>
On Linux, when an fd goes through a unix socket with SCM_RIGHTS, it is duplicated into the receiving process: both prosesses have their own file descriptor pointing to the same underlying file description. The number of the fd is likely different in each process.
<smallville7123>
yea
<kennylevinsen>
smallville7123: that's not quite right: You send the fd (with DuplicateHandle), and then you send the fd *value*.
<pq>
That's what the cmsg and SCM_RIGHTS magic is needed. If you just send a number, it'll be just a number and not an fd.
<smallville7123>
yea, but the fd is the one *returned* by DuplicateHandle, right?
<smallville7123>
winsockets posseses no such magic tho :)
<kennylevinsen>
smallville7123: no, the "fd" is already in the target process. What DuplicateHandle gives you is the numeric value of the handle, which is only valid in the target process
<pq>
Sounds like the return value of DuplicateHandle() is just a number in the sender, but a handle with what number exists in the receiver.
<kennylevinsen>
i.e., if you duplicate fd 1 into the target process in get 2 back, that means that in the target process an fd named "2" exists
<smallville7123>
kennylevinsen: which we then need to send to the target process so it can then open it, right?
<pq>
no need to open, it's already open in the target process
<smallville7123>
or rather, so it knows which fd it should be opening
<kennylevinsen>
you have to send the value so it can pass it to other library/system calls
<smallville7123>
yea
<kennylevinsen>
but the fd is already open, all accesses granted, yadda yadda
<smallville7123>
it just needs to be able to find it :)
<smallville7123>
kinda like sending the shm things so the recipient is able to open it
<smallville7123>
locate and open*
<smallville7123>
eg, client opens "foo", client sends "foo" to server so the server can open "foo" :)
<pq>
btw. libwayland does dup() fds on marshall call, but that's only so that the caller can close its fds immediately after the call without flushing to the socket. The actual sending doesn't need dup().
<kennylevinsen>
it's not sent, the protocol relies on both parties being able to inspect the connection
<smallville7123>
which winsocks doesnt seem to be able to do
<pq>
smallville7123, Wayland does not have protocol for sending my pid, but also if you send a pid, you can also lie about it, so it cannot be trusted.
<smallville7123>
by faking/overriding getpid() ?
<pq>
by deciding to send whatever
<smallville7123>
what if the pid is sent internally by libwayland ?
<pq>
therefore we don't send pid but instead ask the kernel who is on the other end
<pq>
there is no protocol for that, and a client libwayland could be hacked
kts has quit [Quit: Leaving]
<pq>
...actually, not "who is on the other end" but "who initiated the connection".
<smallville7123>
eg, inside of `wl_display_connect` or `wl_display_connect_to_fd`
<kennylevinsen>
not all clients or servers use libwayland, so values from the other side are not trustworthy
<kennylevinsen>
so they can't be allowed to have security consequences
<kennylevinsen>
not sure if duplicatehandle into arbitrary processes as a result of a malicious client would be dangerous or just suboptimal though
<smallville7123>
"When a client is connected to the proxy, the proxy can use getpeername() to query the socket for the remote client IP/Port (or use the IP/Port reported by accept()) and getsockname() to get its local server IP/Port. Then the proxy can use GetTcpTable2() (IPv4) or GetTcp6Table2() (IPv6) to retrieve a list of active TCP connections and loop through it looking for a connection that matches the IP/Port pairs. If found, the list entry will tell you the
<smallville7123>
process ID that owns that connection."
<smallville7123>
hmm "Using GetTcpTable or AllocateAndGetTcpExTableFromStack is not a workaround. It's actually how other netstat-type applications work."
<pq>
nothing, but compositors might use them for... umm. Hmm.
<pq>
logging, and maybe a force-kill-client hotkey
ofourdan has joined #wayland
<emersion>
some sandboxes may use a different uid/gid, that wopuld avoid the PID race issues (e.g. Android does that for each app)
<pq>
it's not a secure way of identifying the client anyway
<emersion>
why is that?
<kennylevinsen>
(being handles on windows, I don't think it would suffer from any PID race)
<pq>
read wl_client_get_credentials() doc, it's the process that opened the connection and not the process that is currently talking.
<emersion>
yes, that's fine
<pq>
so if legit client forgets to set CLOEXEC and forks and execs a malicious program (perhaps dying itself in the process), the pid is no longer correct
<smallville7123>
hmm
<emersion>
exec doesn't change uid/gid
<pq>
oh, the question was about uid and gid, not pid
<pq>
you might as well not implement wl_client_get_credentials()