Re: Problems with the (new) implementation of AF_UNIX datagram sockets

[Ken Brown <kbrown@cornell.edu>]

On 4/16/2021 10:54 PM, Mark Geisert wrote:
> Corinna Vinschen wrote:
>> On Apr 15 16:50, Mark Geisert wrote:
>>> Ken Brown wrote:
>>>> On 4/15/2021 9:58 AM, Corinna Vinschen wrote:
>>>>> On Apr 15 09:16, Ken Brown wrote:
>>>>>> On 4/15/2021 7:49 AM, Corinna Vinschen wrote:
>>>>>> [...]
>>>>>>> Another idea might be to implement send/recv on a DGRAM socket a bit
>>>>>>> like accept.  Rather than creating a single_instance socket, we create a
>>>>>>> max_instance socket as for STREAM socket listeners.  The server side
>>>>>>> accepts the connection at recv and immediately opens another pipe
>>>>>>> instance, so we always have at least one dangling instance for the next
>>>>>>> peer.
>>>>>>
>>>>>> I thought about that, but you would still have the problem (as in 1 above)
>>>>>> that the pipe instance isn't available until recv is called.
>>>>>
>>>>> There always is at least one instance.  Do you mean, two clients are
>>>>> trying to send while the server is idly playing with his toes?
>>>>
>>>> Yes.  That was essentially the situation in the test case attached to
>>>>
>>>>     https://cygwin.com/pipermail/cygwin/2021-April/248210.html
>>>>
>>>> It was actually one client sending many messages while the server was
>>>> playing with his toes, but the effect was the same.
>>>
>>> Sending datagrams between processes on the same system could be thought of
>>> as similar to sending/receiving messages on a POSIX message queue.  Though
>>> the mq_* man pages make it seem like mqs are intended for within-process
>>> messaging.  But if a datagram receiver created a message queue that datagram
>>> senders could open, couldn't that provide buffering and allow multiple
>>> clients?  Kindly ignore if insane.
>>
>> Interesting idea, actually.  Message queues already implement a lot of
>> what a unix socket needs in terms of sending/receiving data.  The pipe
>> would only be needed for credential and descriptor passing, ultimately :)
> 
> One might be able to deal with credentials/descriptor passing within the message 
> queue by using message priority to distinguish the "message" types.  
> mq_receive() always gives you the oldest, highest priority, message available in 
> the queue.
> 
> I'll have to look over the usual DGRAM references again, but OTTOMH if 
> credentials are just euids and egids maybe they could be handled as permissions 
> on the file backing the message queue.  If the filename (in a particular name 
> space we set up) is just the port number one could treat ENOENT as meaning 
> nobody listening on that port, while EPERM could result from credentials not 
> matching the file's permissions.  Makes some sense but I'm unsure if it covers 
> all needs.

A couple of comments:

First, I don't think we want to limit this to DGRAM sockets.  The code in 
fhandler_socket_unix.cc already packages I/O into packets (see 
af_unix_pkt_hdr_t), for both the STREAM and DGRAM cases.  We could just treat 
each packet as a message.  In the STREAM case we would have to deal with the 
case of a partial read, but I think I see how to do that.

Second, I don't think we need to invent a new way of handling credentials.  We 
already have send_sock_info and recv_peer_info.  The only question is whether we 
use a pipe or a message queue.  Corinna, what was your reason for saying we need 
the pipe for that.  Are there security issues with using a message queue?

Ken