POSIX.1-2008 TC1 clarified this, so that O_CLOEXEC,
O_DIRECTORY, and O_NOFOLLOW are also in this list.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
I misapplied Vince's patch, so that his name was not recorded
as the author in the git log. We can at least fix it in the
manual changelog.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Problem:
When connect(2) is executed, the local port number may duplicate.
How reproducible:
When using parameter "net.ipv4.ip_local_port_range", a client may use
the same port to connect to the different sessions on the localhost.
Steps to Reproduce:
1.Change "net.ipv4.ip_local_port_range".
[Example]
net.ipv4.ip_local_port_range = 32768 32770
2.Connect to any two ports of LISTEN by telnet command.
[Example]
# netstat -antp | grep LISTEN
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 2828/smbd
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 2800/vsftpd
#
# telnet 127.0.0.1 139
# telnet 127.0.0.1 21
# telnet 127.0.0.1 21
3.Duplication of a local transmission port.
[Example]
# netstat -antp
tcp 0 0 127.0.0.1:32769 127.0.0.1:139 ESTABLISHED 18147/telnet
tcp 0 0 127.0.0.1:32769 127.0.0.1:21 ESTABLISHED 18157/telnet
Actual results:
The local port number may duplicate.
Expected results:
The local port number doesn't duplicate.
Additional info:
[Investigation]
"man 7 ip" contains following text:
-----------------------------------------------------------------
When listen(2) or connect(2) are called on an unbound socket, it
is automatically bound to a random free port with the local
address set to INADDR_ANY.
-----------------------------------------------------------------
Although indicated as "it is automatically bound to a random free
port", the port number which is not free like in a reproduce
procedure may be bound. Therefore, based on the description of
this "man 7 ip", it can be judged that it is bug to use the local
port where the process duplicated.
--- Comment by Leitner, Flavio on 2/7/2012 2:55 PM ---
It's allowed to have multiple tasks using the same port (as a
result of calling connect(2)) as long as the other connection
information (4-tuple) differs to resolve the conflict. Thus,
it must be an unique 4-tuple consisting of source and
destination IP addresses and port numbers to not conflict.
In the example, the dest port is different.
tcp 0 0 127.0.0.1:32769 127.0.0.1:139 ESTABLISHED 18147/telnet
tcp 0 0 127.0.0.1:32769 127.0.0.1:21 ESTABLISHED 18157/telnet
Reported-by: Peter Schiffer <pschiffe@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
POSIX deliberately leaves this case open, so the man
page should be less specific about what happens.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533232
Reported-by: Zack Weinberg <zackw@panix.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add text to NOTES noting that some MAP_* constants are
defined only if a suitable feature test macro is defined.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542601
Reported-by: Török Edwin <edwintorok@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Denys Vlasenko