[1003.1(2016)/Issue7+TC2 0001337]: Clarify socket option values after accept()
The following issue has been set as RELATED TO issue 411. == https://austingroupbugs.net/view.php?id=1337 == Reported By:eblake Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1337 Category: System Interfaces Type: Omission Severity: Objection Priority: normal Status: New Name: Eric Blake Organization: Red Hat User Reference: accept vs setsockopt Section:XSH 2.10.16 Page Number:528 Line Number:18538 Interp Status: --- Final Accepted Text: == Date Submitted: 2020-04-29 17:41 UTC Last Modified: 2020-05-18 15:23 UTC == Summary:Clarify socket option values after accept() == Relationships ID Summary -- related to 411 adding atomic FD_CLOEXEC support related to 0001318 Define close-on-fork flag == Issue History Date ModifiedUsername FieldChange == 2020-04-29 17:41 eblake New Issue 2020-04-29 17:41 eblake Name => Eric Blake 2020-04-29 17:41 eblake Organization => Red Hat 2020-04-29 17:41 eblake User Reference=> accept vs setsockopt 2020-04-29 17:41 eblake Section => XSH 2.10.16 2020-04-29 17:41 eblake Page Number => 528 2020-04-29 17:41 eblake Line Number => 18538 2020-04-29 17:41 eblake Interp Status => --- 2020-04-29 17:42 eblake Relationship added child of 411 2020-04-29 17:43 eblake Relationship added related to 0001318 2020-05-18 15:23 geoffclare Relationship replacedrelated to 411 ==
[1003.1(2016)/Issue7+TC2 0001337]: Clarify socket option values after accept()
The following issue has been set as RELATED TO issue 0001318. == https://www.austingroupbugs.net/view.php?id=1337 == Reported By:eblake Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1337 Category: System Interfaces Type: Omission Severity: Objection Priority: normal Status: New Name: Eric Blake Organization: Red Hat User Reference: accept vs setsockopt Section:XSH 2.10.16 Page Number:528 Line Number:18538 Interp Status: --- Final Accepted Text: == Date Submitted: 2020-04-29 17:41 UTC Last Modified: 2020-04-29 17:42 UTC == Summary:Clarify socket option values after accept() == Relationships ID Summary -- related to 0001318 Define close-on-fork flag child of411 adding atomic FD_CLOEXEC support == Issue History Date ModifiedUsername FieldChange == 2020-04-29 17:41 eblake New Issue 2020-04-29 17:41 eblake Name => Eric Blake 2020-04-29 17:41 eblake Organization => Red Hat 2020-04-29 17:41 eblake User Reference=> accept vs setsockopt 2020-04-29 17:41 eblake Section => XSH 2.10.16 2020-04-29 17:41 eblake Page Number => 528 2020-04-29 17:41 eblake Line Number => 18538 2020-04-29 17:41 eblake Interp Status => --- 2020-04-29 17:42 eblake Relationship added child of 411 2020-04-29 17:43 eblake Relationship added related to 0001318 ==
[1003.1(2016)/Issue7+TC2 0001337]: Clarify socket option values after accept()
The following issue has been set CHILD OF issue 411. == https://www.austingroupbugs.net/view.php?id=1337 == Reported By:eblake Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1337 Category: System Interfaces Type: Omission Severity: Objection Priority: normal Status: New Name: Eric Blake Organization: Red Hat User Reference: accept vs setsockopt Section:XSH 2.10.16 Page Number:528 Line Number:18538 Interp Status: --- Final Accepted Text: == Date Submitted: 2020-04-29 17:41 UTC Last Modified: 2020-04-29 17:42 UTC == Summary:Clarify socket option values after accept() == Relationships ID Summary -- child of411 adding atomic FD_CLOEXEC support == Issue History Date ModifiedUsername FieldChange == 2020-04-29 17:41 eblake New Issue 2020-04-29 17:41 eblake Name => Eric Blake 2020-04-29 17:41 eblake Organization => Red Hat 2020-04-29 17:41 eblake User Reference=> accept vs setsockopt 2020-04-29 17:41 eblake Section => XSH 2.10.16 2020-04-29 17:41 eblake Page Number => 528 2020-04-29 17:41 eblake Line Number => 18538 2020-04-29 17:41 eblake Interp Status => --- 2020-04-29 17:42 eblake Relationship added child of 411 ==
[1003.1(2016)/Issue7+TC2 0001337]: Clarify socket option values after accept()
The following issue has been SUBMITTED. == https://www.austingroupbugs.net/view.php?id=1337 == Reported By:eblake Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1337 Category: System Interfaces Type: Omission Severity: Objection Priority: normal Status: New Name: Eric Blake Organization: Red Hat User Reference: accept vs setsockopt Section:XSH 2.10.16 Page Number:528 Line Number:18538 Interp Status: --- Final Accepted Text: == Date Submitted: 2020-04-29 17:41 UTC Last Modified: 2020-04-29 17:41 UTC == Summary:Clarify socket option values after accept() Description: While the standard is clear that all sockets have default settings for socket options, and that some defaults are implementation-defined (for example, "The default value for the SO_RCVBUF option value is implementation-defined, and may vary by protocol." line 18628), it is silent on whether a non-default socket option set on a listening socket is required/permitted to be inherited into the new socket created by accept(). As there are existing implementations which inherit some but not all socket options (see https://stackoverflow.com/questions/5968132/are-socket-options-inherited-across-accept-from-the-listening-socket), the best course of action is to just clarify that portable applications cannot rely on option inheritance. Also, the text states "All of the options have defaults" (line 18538) then contradicts itself "SO_TYPE has no default value" (line 18672). Desired Action: [note: this change assumes that https://www.austingroupbugs.net/view.php?id=411 adding accept4() is applied] Change page 528 line 18538 (XSH 2.10.16 Use of Options) from:All of the options have defaults.to:All of the options usable with setsockopt( ) have defaults. For each option where a default value is listed as implementation-defined, the implementation also controls whether a socket created by accept( ) or accept4( ) starts with the option reset to the original default value, or inherited as the value previously customized on the original listening socket. At page 565 line 19882 [XSH accept() DESCRIPTION), add a paragraph:It shall be implementation-defined which socket options, if any, on the accepted socket will have a default value determined by a value previously customized by setsockopt( ) on socket, rather than the default value used for other new sockets. At page 569 line 19912 [XSH accept() APPLICATION USAGE), add a new paragraph:Many socket options are described as having implementation-defined default values, which may differ according to the protocol in use by the socket. Existing practice differs on whether socket options such as SO_SNDBUF that were customized on the original listening socket will impact the corresponding option on the newly returned socket. Implementations are permitted to allow inheritance of customized settings where it makes sense, although the most portable approach for applications is to limit setsockopt( ) customizations to only the accepted socket. At page 1924 line 62032 [XSH setsockopt() APPLICATION USAGE), add a new paragraph:It is implementation-defined which socket options, if any, are inherited from a listening socket to an accepted socket by accept( ) or accept4( ). == Issue History Date ModifiedUsername FieldChange == 2020-04-29 17:41 eblake New Issue 2020-04-29 17:41 eblake Name => Eric Blake 2020-04-29 17:41 eblake Organization => Red Hat 2020-04-29 17:41 eblake User Reference=> accept vs setsockopt 2020-04-29 17:41 eblake Section => XSH 2.10.16 2020-04-29 17:41 eblake Page Number => 528 2020-04-29 17:41 eblake Line Number => 18538 2020-04-29 17:41 eblake Interp Status => --- ==
