A NOTE has been added to this issue. 
====================================================================== 
https://austingroupbugs.net/view.php?id=561 
====================================================================== 
Reported By:                eblake
Assigned To:                ajosey
====================================================================== 
Project:                    1003.1(2008)/Issue 7
Issue ID:                   561
Category:                   System Interfaces
Type:                       Error
Severity:                   Objection
Priority:                   normal
Status:                     Under Review
Name:                       Eric Blake 
Organization:               Red Hat 
User Reference:             ebb.sockaddr_un 
Section:                    <sys/un.h> 
Page Number:                403 
Line Number:                13515 
Interp Status:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2012-05-03 16:14 UTC
Last Modified:              2022-11-28 16:24 UTC
====================================================================== 
Summary:                    NUL-termination of sun_path in Unix sockets
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0001593 specify whether struct sockaddr_un.sun_...
====================================================================== 

---------------------------------------------------------------------- 
 (0006085) geoffclare (manager) - 2022-11-28 16:24
 https://austingroupbugs.net/view.php?id=561#c6085 
---------------------------------------------------------------------- 
Page and line numbers are for Issue 8 draft 2.1.

At page 403 line 13894 section <sys/un.h> DESCRIPTION, change:
<blockquote><tt>char     sun_path[]</tt>   Socket pathname.</blockquote>
to:
<blockquote><tt>char     sun_path[<i>size</i>]</tt>   Socket pathname
storage.

The <i>sun_path</i> member shall be the last member of the
<b>sockaddr_un</b> structure, where <i>size</i> 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.</blockquote>

At page 403 line 13899 section <sys/un.h> APPLICATION USAGE, change:
<blockquote>The size of <i>sun_path</i> 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.</blockquote>
to: 
<blockquote>The size of <i>sun_path</i> 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 <i>sun_path</i> is required to be the
last member of the struct, an application can deduce the size by using
<tt>sizeof(struct sockaddr_un) - offsetof(struct sockaddr_un,
sun_path)</tt>.</blockquote>

At page 403 line 13911 section <sys/un.h> RATIONALE, change from "None"
to:
<blockquote>Some implementations expose a macro <tt>SUN_LEN</tt> for the
size of a pathname stored in <tt>sun_path</tt>.  However, this was not
widely adopted, and differences on how a terminating NUL byte is
interpreted between implementations did not make it worth
standardizing.</blockquote>

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:
<blockquote>For AF_UNIX sockets, it is recommended that <i>address</i>
points to a buffer of length greater than <tt>sizeof(struct
sockaddr_un)</tt> which has been initialized with null bytes. That way,
even if the implementation supports the use of all bytes of <i>sun_path</i>
without a terminating null byte, the larger buffer guarantees that the
<i>sun_path</i> member can then be passed to other interfaces that expect a
null-terminated string.  If no truncation occurred based on the input value
of <i>address_len</i>, It is unspecified whether the returned
<i>address_len</i> will be <tt>sizeof(struct sockaddr_un)</tt>, or merely a
value at least as large as <tt>offsetof(struct sockaddr_un, sun_path)</tt>
plus the number of non-null bytes stored in <i>sun_path</i>.</blockquote>

At page 604 line 21124 section bind() DESCRIPTION, after applying bug 1605
change:
<blockquote>If the address family of the socket is AF_UNIX and the pathname
in <i>address</i> names an existing file, including a symbolic link,
<i>bind</i>() shall treat the address as already in use; see ERRORS
below.</blockquote>
to:
<blockquote>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
<i>sun_path</i> member of <i>address</i> as a <b>sockaddr_un</b> structure,
and that <i>address_len</i> is at least <tt>offsetof(struct sockaddr_un,
sun_path) + 1</tt> plus the length of the pathname. If the pathname in the
<i>sun_path</i> member of <i>address</i> names an existing file, including
a symbolic link, <i>bind</i>( ) shall treat the address as already in use;
see ERRORS below.</blockquote>

After page 606 line 21209 section bind() add to APPLICATION USAGE,
and after page 686 line 23737 section connect() add to APPLICATION USAGE:
<blockquote>For AF_UNIX sockets, some implementations support an extension
where<i>address_len</i> does not have to include a null terminator for the
pathname stored in <i>sun_path</i>, 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.</blockquote>

After page 684 line 23647 section connect() add to DESCRIPTION:
<blockquote>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
<i>sun_path</i> member of <i>address</i> as a <b>sockaddr_un</b> structure,
and that <i>address_len</i> is at least <tt>offsetof(struct sockaddr_un,
sun_path) + 1</tt> plus the length of the pathname. </blockquote>

After page 1836 line 60177 section sendto() add to DESCRIPTION:
<blockquote>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
<i>sun_path</i> member of <i>dest_addr</i> as a <b>sockaddr_un</b>
structure, and that <i>dest_len</i> is at least <tt>offsetof(struct
sockaddr_un, sun_path) + 1</tt> plus the length of the
pathname.</blockquote>

After page 1838 line 60255 section sendto() add to APPLICATION USAGE:
<blockquote>For AF_UNIX sockets, some implementations support an extension
where<i>dest_len</i> does not have to include a null terminator for the
pathname stored in <i>sun_path</i>, 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.</blockquote> 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2012-05-03 16:14 eblake         New Issue                                    
2012-05-03 16:14 eblake         Status                   New => Under Review 
2012-05-03 16:14 eblake         Assigned To               => ajosey          
2012-05-03 16:14 eblake         Name                      => Eric Blake      
2012-05-03 16:14 eblake         Organization              => Red Hat         
2012-05-03 16:14 eblake         User Reference            => ebb.sockaddr_un 
2012-05-03 16:14 eblake         Section                   => <sys/un.h>      
2012-05-03 16:14 eblake         Page Number               => 403             
2012-05-03 16:14 eblake         Line Number               => 13515           
2012-05-03 16:14 eblake         Interp Status             => ---             
2012-05-03 17:23 mdempsky       Note Added: 0001226                          
2012-05-03 17:33 eblake         Note Added: 0001227                          
2012-05-03 17:39 mdempsky       Note Added: 0001228                          
2012-05-04 22:21 mkerrisk       Note Added: 0001233                          
2012-06-04 14:15 codonell       Issue Monitored: codonell                    
2022-07-20 20:34 eblake         Relationship added       related to 0001593  
2022-11-28 16:24 geoffclare     Note Added: 0006085                          
======================================================================


  • [1003.1(2008... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
      • Re:... Steffen Nurpmeso via austin-group-l at The Open Group
        • ... Eric Blake via austin-group-l at The Open Group
          • ... Eric Blake via austin-group-l at The Open Group
            • ... Olivier Certner via austin-group-l at The Open Group
              • ... Steffen Nurpmeso via austin-group-l at The Open Group
                • ... Steffen Nurpmeso via austin-group-l at The Open Group
                • ... Geoff Clare via austin-group-l at The Open Group
                • ... Steffen Nurpmeso via austin-group-l at The Open Group
                • ... Thorsten Glaser via austin-group-l at The Open Group
            • ... Steffen Nurpmeso via austin-group-l at The Open Group

Reply via email to