|Anonymous | Login | Signup for a new account||2017-10-23 20:50 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0000561||[1003.1(2008)/Issue 7] System Interfaces||Objection||Error||2012-05-03 16:14||2012-05-04 22:21|
|Final Accepted Text|
|Summary||0000561: NUL-termination of sun_path in Unix sockets|
Several messages on the mail reflector pointed out some issues with Unix
sockets, as provided by <sys/un.h>.
The standard is ambiguous whether a Unix socket filename when passed through
and interface such as getsockname with a too-small size will guarantee NUL
termination of the resulting output; however, many existing applications
assume the presence of a NUL terminator, and may misbehave if one is not
guaranteed. Furthermore, all implementations currently implement sun_path
as the last member of struct sockaddr_un, but without a guarantee, it is
not possible to provide an input structure larger than sockaddr_un in order
to guarantee NUL termination if all bytes of sun_path are allowed to be
Other issues include the fact that POSIX 1003.1g defined a macro SUN_LEN
to help in computing the length of a socket name, but this macro was
not incorporated into POSIX 2008.
Additional requirements need to be added to specify the treatment of all
socket families that bind to a filename. The wording is still a work in
progress, and will be added as a note later; for now, this defect serves
as a placeholder to identify the issue.
|Tags||No tags attached.|
As stated on the mailing list, OpenBSD's solution to this issue was to require space for the NUL terminator in sun_path. Applications that always use sockaddr_un for UNIX socket addresses are then guaranteed that sun_path will be NUL terminated.
Since POSIX doesn't guarantee sun_path will be of any particular size anyway, this shouldn't be a compatibility issue.
Actually, the older POSIX 1003.1g requires sun_path to be at least 100 bytes
(that would imply sun_path of 101 bytes if you require a NUL); although the
current non-normative wording in <sys/un.h> states that sun_path might be as
small as 92 bytes. Does anyone have an example system where sun_path was
less than 100 bytes?
It's not enough to ensure a NUL pointer in sun_path on creation; you must
also consider the guarantees of a NUL pointer on output via functions like
getsockname(), even if the length parameter passed to getsockname() was
smaller than sizeof(struct sockaddr_un).
Our guarantee is that userland apps that use a sockaddr_un for receiving a UNIX socket address via getsockname()/etc will have a NUL terminator. We don't make any NUL termination guarantees if userland allocates less than sizeof(struct sockaddr_un) bytes.
Is it necessary that if a user tries to call getsockname() on a PF_UNIX socket with a sockaddr_in or sockaddr_in6 that the path returned to userspace still be NUL terminated? Why? Userspace can detect when the path was truncated by comparing the returned *socklen or sa_len with the amount of space they allocated. Because currently sun_path isn't guaranteed to be at the end of the sockaddr, a truncated sockaddr has no guaranteed meaning.
|HP-UX has a 92-byte limit on sun_path.|
|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|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|