Problems with the (new) implementation of AF_UNIX datagram sockets

[Corinna Vinschen]

On Apr 17 12:05, Ken Brown wrote:
> On 4/16/2021 10:54 PM, Mark Geisert wrote:
> > Corinna Vinschen wrote:
> > > On Apr 15 16:50, Mark Geisert wrote:
> > > > 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?

Long-standing problem.  The peer sends uid/gid values, but how's the
server to know that these values are correct?  The idea was to replace
this at one point by a server-side call to ImpersonateNamedPipeClient
and to retrieve the credentials of the peer in the server, so we
actually *know* whom we're talking with.


Corinna