From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 19 20:20:59 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3D768E7A for ; Tue, 19 Mar 2013 20:20:59 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id 0749D2D5 for ; Tue, 19 Mar 2013 20:20:59 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id C52A71203C1; Tue, 19 Mar 2013 21:20:45 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id AF9A52848C; Tue, 19 Mar 2013 21:20:45 +0100 (CET) Date: Tue, 19 Mar 2013 21:20:45 +0100 From: Jilles Tjoelker To: Konstantin Belousov Subject: Re: [patch] SOCK_CLOEXEC, SOCK_NONBLOCK and MSG_CMSG_CLOEXEC Message-ID: <20130319202045.GA26721@stack.nl> References: <20130317212353.GD65525@stack.nl> <20130318205957.GM3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130318205957.GM3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 20:20:59 -0000 On Mon, Mar 18, 2013 at 10:59:57PM +0200, Konstantin Belousov wrote: > On Sun, Mar 17, 2013 at 10:23:53PM +0100, Jilles Tjoelker wrote: > > Here are some more modifications to allow creating file descriptors with > > close-on-exec set. Like in linux/glibc, SOCK_CLOEXEC and SOCK_NONBLOCK > > can be OR'ed in socket() and socketpair()'s type parameter, and > > MSG_CMSG_CLOEXEC to recvmsg() makes file descriptors (SCM_RIGHTS) > > atomically close-on-exec. > > The numerical values for SOCK_CLOEXEC and SOCK_NONBLOCK are as in > > NetBSD. MSG_CMSG_CLOEXEC is the first free bit for MSG_*. > > I do not pass the SOCK_* flags to MAC because this may cause incorrect > > failures and can be done later via fcntl() anyway. I expect audit to > > cope with the new flags. > > For MSG_CMSG_CLOEXEC, I had to change unp_externalize to take a flags > > argument. > This looks fine to me. Thanks for the review. > The only note I have, which is not directly related to your patch, > is the recvmsg(2) behaviour when the undefined flag is passed. > The syscall silently ignores the flags. I think this is quite wrong, > and would cause interesting (security) implications if the program > using the MSG_CMSG_CLOEXEC is run on older kernel which does not > interpret the flag. This is indeed unfortunate and it also affects open(2). It may have originally been done for reasons of modularity; the sys_open() and kern_open() need not know about the valid flag bits this way and a device driver or filesystem can define new bits. The effect of an older kernel ignoring MSG_CMSG_CLOEXEC is probably not that bad, considering that running new userland on an old kernel is not supported. Most compatibility shims for MSG_CMSG_CLOEXEC and similar flags (such as the one in Wayland) simply contain the race condition, so you lose anyway with an old kernel. It would be possible to use closefrom() or an emulation of it or to lock fork() conditionally on the necessary CLOEXEC flags not being available but it appears that people do not go to that trouble. > Might be, we should start returning EINVAL for unknown flag, despite > SUSv4 not specifying the condition ? Per POSIX it is valid to do this but it might cause a compatibility problem if there are applications that pass garbage in flags. -- Jilles Tjoelker