Hang in tstream_bsd_writev_handler when W10 (at least) calls lsa_LookupSids2 with 1789 SIDs.

[Richard Sharpe]

Hi folks,

QA sent me a doozie.

Samba 4.3.0 pre-release.

They created a file with 1814 ACEs in its ACL using PowerShell
(although I had to fix their script because it took hours because of
the way they did it,)

Then, when they used the ACL Editor to retrieve and display the SD,
Samba hung in tstream_bsd_writev_handler calling writev.

The problem seems to be that there is a little less than 110,xxx bytes
(that was the size of the RPC being sent back) on the UNIX socket that
the RPC layer uses to communicate with the SMB layer, and we do not
use non-blocking sockets there. So, all those fragments are processed
as queued events, but the last one blocks and none of the events that
would remove data from the socket ever get to run and Samba is hung.

If you look at the code in net/unix and net/core in Linux you will see
that AF_UNIX sockets do not implement setsockopt and I could not find
any way to increase the buffer size for UNIX sockets, so I solved the
problem by changing tstream_bsd_writev_send to never call
tstream_bsd_writev_handler but call tstream_bsd_set_writeable_handler,
however, the comment about the performance bothers me. I also could
not find a way to make that the behavior only for AF_UNIX sockets.

Is there a better way?

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)