Minutes of the 28th November 2022 Teleconference Austin-1275 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 29th November 2022 Attendees: Don Cragun, IEEE PASC OR Mark Ziegast, SHware Systems Dev. Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR Eric Ackermann, HPI, University of Potsdam Geoff Clare, The Open Group Andrew Josey, The Open Group Tom Thompson, IEEE * General news This was a call dedicated to general bugs. Andrew noted that the publication draft of the New APIs Part 2 document has been prepared and sent for the final approvals internally at The Open Group. It could take a few weeks for final publication. * Carried Forward This section trimmed -- see Austin/1264 Bug 1593: specify whether struct sockaddr_un.sun_path can be a flexible array member OPEN https://austingroupbugs.net/view.php?id=1593 Wait for Eric to complete his action on bug 561 Bug 1406: clarification of SEEK_END when current pointer doesn't match buffer size OPEN https://austingroupbugs.net/view.php?id=1406 Actions carried forward: ACTION: Andrew to contact Rich Felker (dalias) and Alan Coopersmith (Solaris) for feedback. Completed ACTION: Eric B to contact glibc folks. Bug 1616: Standardize mktemp utility OPEN https://austingroupbugs.net/view.php?id=1616 We will need a sponsor; it is not suitable for inclusion in Issue 8. ACTION: Eric to ask The Open Group to sponsor adding the mktemp utility (for Issue 9). Bug 1291: Add method to obtain pthread attributes OPEN https://austingroupbugs.net/view.php?id=1291 Needs additional details and sponsor for Issue 9 Bug 1616: Standardize mktemp utility OPEN https://austingroupbugs.net/view.php?id=1616 Will need a sponsor; not suitable for inclusion in Issue 8. AI Eric to ask The Open Group to sponsor adding the mktemp utility (for Issue 9). * Current Business Bug 0000561: NUL-termination of sun_path in Unix sockets Accepted as Marked http://austingroupbugs.net/view.php?id=561 This item is tagged for Issue 8 Page and line numbers are for Issue 8 draft 2.1. At page 403 line 13894 section DESCRIPTION, change: char sun_path[] Socket pathname. to: char sun_path[size] Socket pathname storage. The sun_path member shall be the last member of the sockaddr_un structure, where size shall be an implementation-provided constant size of at least 92 bytes. This size value need not be accessible as a constant available for use in the application namespace. At page 403 line 13899 section APPLICATION USAGE, change: The size of sun_path has intentionally been left undefined. This is because different implementations use different sizes. For example, 4.3 BSD uses a size of 108, and 4.4 BSD uses a size of 104. Since most implementations originate from BSD versions, the size is typically in the range 92 to 108. to: The size of sun_path is required to be constant, but intentionally does not have a specified name for that constant. Historically, different implementations used different sizes. For example, 4.3 BSD used a size of 108, and 4.4 BSD used a size of 104. Since most implementations originate from BSD versions, the size is typically in the range 92 to 108. However, because sun_path is required to be the last member of the struct, an application can deduce the size by using sizeof(struct sockaddr_un) - offsetof(struct sockaddr_un, sun_path). At page 403 line 13911 section RATIONALE, change from "None" to: Some implementations expose a macro SUN_LEN for the size of a pathname stored in sun_path. However, this was not widely adopted, and differences on how a terminating NUL byte is interpreted between implementations did not make it worth standardizing. After page 543 line 19233 section accept() and page 1745 line 57250 section recvfrom(), add to APPLICATION USAGE, and at page 1055 line 36136 section getpeername() and page 1081 line 36940 section getsockname(), change APPLICATION USAGE from "None" to: For AF_UNIX sockets, it is recommended that address points to a buffer of length greater than sizeof(struct sockaddr_un) which has been initialized with null bytes. That way, even if the implementation supports the use of all bytes of sun_path without a terminating null byte, the larger buffer guarantees that the sun_path member can then be passed to other interfaces that expect a null-terminated string. If no truncation occurred based on the input value of address_len, It is unspecified whether the returned address_len will be sizeof(struct sockaddr_un), or merely a value at least as large as offsetof(struct sockaddr_un, sun_path) plus the number of non-null bytes stored in sun_path. At page 604 line 21124 section bind() DESCRIPTION, after applying bug 1605 change: If the address family of the socket is AF_UNIX and the pathname in address names an existing file, including a symbolic link, bind() shall treat the address as already in use; see ERRORS below. to: If the address family of the socket is AF_UNIX, the application shall ensure that a null terminator after the pathname is included in the sun_path member of address as a sockaddr_un structure, and that address_len is at least offsetof(struct sockaddr_un, sun_path) + 1 plus the length of the pathname. If the pathname in the sun_path member of address names an existing file, including a symbolic link, bind( ) shall treat the address as already in use; see ERRORS below. After page 606 line 21209 section bind() add to APPLICATION USAGE, and after page 686 line 23737 section connect() add to APPLICATION USAGE: For AF_UNIX sockets, some implementations support an extension whereaddress_len does not have to include a null terminator for the pathname stored in sun_path, which in turn allows a pathname to be one byte longer. However, such usage is not portable, and carries a risk of accessing beyond the intended bounds of the pathname length. After page 684 line 23647 section connect() add to DESCRIPTION: If the address family of the socket is AF_UNIX, the application shall ensure that a null terminator after the pathname is included in the sun_path member of address as a sockaddr_un structure, and that address_len is at least offsetof(struct sockaddr_un, sun_path) + 1 plus the length of the pathname. After page 1836 line 60177 section sendto() add to DESCRIPTION: If the address family of the socket is AF_UNIX, the application shall ensure that a null terminator after the pathname is included in the sun_path member of dest_addr as a sockaddr_un structure, and that dest_len is at least offsetof(struct sockaddr_un, sun_path) + 1 plus the length of the pathname. After page 1838 line 60255 section sendto() add to APPLICATION USAGE: For AF_UNIX sockets, some implementations support an extension wheredest_len does not have to include a null terminator for the pathname stored in sun_path, which in turn allows a pathname to be one byte longer. However, such usage is not portable, and carries a risk of accessing beyond the intended bounds of the pathname length. Bug 1620: is the empty string a valid pathname? Rejected https://austingroupbugs.net/view.php?id=1620 If an empty/null string was not a valid pathname, 4.14 Pathname Resolution would not be able to use the phrase "null pathname" as such a thing would not exist. Also, if it was not a valid pathname you would expect interfaces that take a pathname to return an EINVAL error when the argument is empty, but they don't - they return an ENOENT error, indicating that it is a valid pathname that does not resolve. The definition of pathname in XBD chapter 3 includes a cross-reference to 4.14 Pathname Resolution; We don't see the need to repeat any detail from that section in the definition. Bug 0000251: Forbid newline, or even bytes 1 through 31 (inclusive), in filenames OPEN http://austingroupbugs.net/view.php?id=251 We started on this item and will continue next time. Next Steps ---------- The next calls are on: Thu 2022-12-01 (general bugs) Mon 2022-12-05 (general bugs) The calls are for 90 minutes Calls are anchored on US time. (8am Pacific) Please check the calendar invites for dial in details. Bugs are at: https://austingroupbugs.net An etherpad is usually up for the meeting, with a URL using the date format as below: https://posix.rhansen.org/p/20xx-mm-dd (For write access this uses The Open Group single sign on, for those individuals with gitlab.opengroup.org accounts. Please contact Andrew if you need to be setup)