From owner-freebsd-bugs Fri Oct 26 8:42:28 2001 Delivered-To: freebsd-bugs@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 4332A37B406 for ; Fri, 26 Oct 2001 08:42:22 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9QFgJZ71206; Fri, 26 Oct 2001 11:42:19 -0400 (EDT) (envelope-from wollman) Date: Fri, 26 Oct 2001 11:42:19 -0400 (EDT) From: Garrett Wollman Message-Id: <200110261542.f9QFgJZ71206@khavrinen.lcs.mit.edu> To: "Andrew R. Reiter" Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: bin/31507: Risk of buffer overflow in struct sockaddr_un In-Reply-To: References: <200110261520.f9QFK1e07958@freefall.freebsd.org> Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > Does this handle off-by-one situations? Also, in terms of using strncpy, > would it be more wise to utilize strlcpy() rather than a > strncpy()/buf[sizeof(buf)-1] = 0; throughout the tree? Or has strlcpy() > had some negative feedback? strlcpy() is non-portable, and in any case the kernel takes care of null-termination. (In FreeBSD it is actually permissible to use a larger buffer; see kern/uipc_usrreq.c:unp_bind(). Portable applications cannot depend on this.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message