lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f215d6b5-0aed-a3d1-39d3-f3bf12fdfc78@gmail.com>
Date:   Mon, 6 Apr 2020 13:47:46 +0200
From:   "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:     Eric Dumazet <eric.dumazet@...il.com>,
        netdev <netdev@...r.kernel.org>, linux-man@...r.kernel.org
Cc:     mtk.manpages@...il.com
Subject: Re: connect() man page

Hello Eric,

My apologies for the delayed reply.

On 2/12/20 6:50 PM, Eric Dumazet wrote:
> Hi Michael
> 
> connect() man page seems obsolete or confusing :
> 
>    Generally,  connection-based  protocol  sockets may successfully
>    connect() only once; connectionless protocol  sockets  may  use
>    connect()  multiple times  to  change  their association.
>    Connectionless sockets may dissolve the association by connecting to
>    an address with the sa_family  member  of sockaddr set to AF_UNSPEC
>    (supported on Linux since kernel 2.2).
> 
> 
> 1) At least TCP has supported AF_UNSPEC thing forever.

Thanks for the heads-up,

> 2) By definition connectionless sockets do not have an association,
>    why would they call connect(AF_UNSPEC) to remove a connection 
>    which does not exist ...

Calling connect() on a connectionless socket serves two purposes:
a) Assigns a default outgoing address for datagrams (sent using write(2)).
b) Causes datagrams sent from sources other than the peer address to be 
   discarded.

Both of these things are true in AF_UNIX and the Internet domains.
Using connect(AF_UNSPEC) allows the local datagram socket to clear 
this association (without having to connect() to a *different* peer),
so that now it can send datagrams to any peer and receive
datagrams for any peer, (I've just retested all of this.)

> 
> Maybe we should rewrite this paragraph to match reality, since 
> this causes confusion.
> 
> 
>    Some protocol sockets may successfully connect() only once.
>    Some protocol sockets may use connect() multiple times  to  change
>    their association.
>    Some protocol sockets may dissolve the association by connecting to
>    an address with the sa_family member of sockaddr set to AF_UNSPEC
>    (supported on Linux since kernel 2.2).

When I first saw your note, I was afraid that I had written
the offending text. But, I see it has been there since the 
manual page was first added in 1992 (other than the piece 
"(supported since on Linux since kernel 2.2)", which I added in
2007). Perhaps it was true in 1992.

Anyway, I confirm your statement about TCP sockets. The 
connect(AF_UNSPEC) thing works; thereafter, the socket may be
connected to another socket.

Interestingly, connect(AF_UNSPEC) does not seem to work for
UNIX domain stream sockets. (My light testing gives an EINVAL
error on connect(AF_UNSPEC) of an already connected UNIX stream
socket. I could not easily spot where this error was being
generated in the kernel though.)

I like your proposed text, but would like to include more
information. How about this:

       Some protocol sockets (e.g., UNIX domain stream sockets) may  suc‐
       cessfully connect() only once.

       Some  protocol  sockets  (e.g.,  datagram  sockets in the UNIX and
       Internet domains) may use connect() multiple times to change their
       association.

       Some protocol sockets (e.g., TCP sockets as well as datagram sock‐
       ets in the UNIX and Internet domains) may dissolve the association
       by  connecting to an address with the sa_family member of sockaddr
       set to AF_UNSPEC; thereafter,  the  socket  can  be  connected  to
       another  address.   (AF_UNSPEC  is supported on Linux since kernel
       2.2.)

?

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ