From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-developers@cygwin.com
Subject: Re: Problems with the (new) implementation of AF_UNIX datagram sockets
Date: Mon, 19 Apr 2021 10:48:39 +0200 [thread overview]
Message-ID: <YH1D5/+BxBGQYYw6@calimero.vinschen.de> (raw)
In-Reply-To: <27dadaaf-68d5-a529-2c87-9a08ef1f86df@cornell.edu>
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
prev parent reply other threads:[~2021-04-19 8:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-14 16:15 Ken Brown
2021-04-15 11:49 ` Corinna Vinschen
2021-04-15 13:16 ` Ken Brown
2021-04-15 13:58 ` Corinna Vinschen
2021-04-15 14:53 ` Ken Brown
2021-04-15 23:50 ` Mark Geisert
2021-04-16 9:37 ` Corinna Vinschen
2021-04-17 2:54 ` Mark Geisert
2021-04-17 16:05 ` Ken Brown
2021-04-19 8:48 ` Corinna Vinschen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YH1D5/+BxBGQYYw6@calimero.vinschen.de \
--to=corinna-cygwin@cygwin.com \
--cc=cygwin-developers@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).