[PATCH xserver] os: Call FlushClient() before sending FD-passing messages

[Alexander Volkov]

03.04.2018 21:57, Keith Packard пишет:
> Alexander Volkov <a.volkov at rusbitech.ru> writes:
>
>> Yes, it would be easier to fix this in libxcb, but I believe that it
>> would be more correct to do this in the X server. At least I want to
>> try to fix the X server.
> Hrm.
>
> The problem is that there are two streams of data here -- the stream of
> fds and the stream of replies. xcb currently insists that they remain
> aligned so that any fds are associated with the reply data received in
> the same recvmsg operation. This allows an X server to send fds which
> the client is not expecting, with the client can silently closing
> them.
>
> If we let the two streams run un-aligned, then there will be a queue of
> received fds that should (unless there's a bug) eventually get
> associated with the correct reply. The requirement here is looser -- we
> just need to make sure the fds arrive no later than the reply data. This
> seems much easier to achieve, and in fact the current X server code does
> this today.
>
> Changing xcb to allow early fds involves removing code that closes fds
> received before the associated reply.
>
> Changing the X server to ensure that fds are delivered exactly with the
> associated reply data involves adding code to queue the fds and insert
> additional flushes to make sure the kernel writes the fds with the start
> of the reply, and then making sure that xcb doesn't discard fds received
> with a partial reply.
>
> Given these two possible solutions, I'd like to suggest that we might
> prefer the simpler one.
libxcb stores received file descriptors in the buffer of size 16 
(XCB_MAX_PASS_FD).
Whether it's possible that the X server will send more than 16 fds in a 
single reply
and overflow the libxcb's buffer?