AF_UNIX status report

[Ken Brown]

On 11/5/2020 12:21 PM, Corinna Vinschen wrote:
> On Nov  5 09:23, Ken Brown via Cygwin-developers wrote:
>> OK, here's how I imagine this working:
>>
>> A process wants to send a file descriptor fd, so it creates a msghdr with an
>> SCM_RIGHTS cmsghdr and calls sendmsg.  The latter creates and sends an admin
>> packet A containing the fhandler for fd, and then it sends the original
>> packet P.
>>
>> At the receiving end, recvmsg sees packet A first (recvmsg is always
>> checking for admin packets anyway whenever it's called).  It stores the
>> fhandler somewhere.  When it then reads packet P, it retrieves the stored
>> fhandler, fiddles with it (duplicating handles, etc.), and creates the new
>> file descriptor.
> 
> Actually, this needs to be implemented in a source/dest-independent
> manner.  Only the server of the named pipe can impersonate the client.
> So the server side should do the job of duplicating the handles.  If the
> sever is also the source of SCM_RIGHTS, it should send the fhandler with
> already duplicated handles.

Ah, OK.  I was thinking of it differently.  Rather than having the server 
impersonate the client, I was thinking that the sender would send its winpid as 
part of its admin packet, which the receiver could then use to get a handle to 
the sender's process.  The receiver could then duplicate the handles.  But maybe 
your approach is better.  I'll have to rethink it.

>> Does this seem reasonable?  The main thing bothering me is the lack of
>> atomicity.  I don't like the gap between the sending of the two packets A
>> and P, and similarly for the receiving.  I thought about using the io_lock
>> to at least make sure that the two packets are adjacent in the pipe, but I
>> don't know if we want to tie up the io_lock for that long.
>>
>> Also, the sending process might be sending several file descriptors at once,
>> so that there would be several admin packets to be sent (unless we want to
>> cram it all into one).
> 
> We can safely assume that pipe packets up to 64K are sent and received
> atomically.
> 
> In most cases this shouldn't be much of a problem.  Most scenarios using
> SCM_RIGHTS send no or only a minor payload.  Most scenarios share a
> single or only a handful of descriptors.
> 
> Apart from that, Linux also defines SCM_MAX_FD, the max. number of
> descriptors in a single sendmsg call.  If the number of descriptors
> is larger, sendmsg returns EINVAL.  SCM_MAX_FD is 253 on Linux, but
> 
> What that means to us is, we can choose our own SCM_MAX_FD and just
> return EINVAL if the number of descriptors is uncomfortably high.
> The max. number of descriptors should be limited so that all descriptors
> fit into 64K, or even 32K, just to leave space for payload.
> Assuming a size of about 600 bytes per fhandler, 50 might be a good
> candidate for SCM_MAX_FD.  I'd say even 32 would be sufficent for most
> scenarios.
> 
> The idea would be to create the packet on the source side with all
> fhandlers in the ancilliary data block, followed by the payload.
> This should typically fit in a 64K package.  If not, only the
> payload needs to be split into multiple packages.  Do we really
> need atomicity there?  Not sure, but only then we'd need an io_lock.
> 
> Does that make sense?

Yes.  Thanks.

Ken