Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
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
Reporter eblake View Status public  
Assigned To ajosey
Priority normal Resolution Open  
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
Summary 0000561: NUL-termination of sun_path in Unix sockets
Description 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
non-NUL.

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.
Desired Action 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.
Attached Files

- Relationships

-  Notes
(0001226)
mdempsky (reporter)
2012-05-03 17:23

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.
(0001227)
eblake (manager)
2012-05-03 17:33

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).
(0001228)
mdempsky (reporter)
2012-05-03 17:39

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.
(0001233)
mkerrisk (reporter)
2012-05-04 22:21

HP-UX has a 92-byte limit on sun_path.

- 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


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker