From owner-svn-src-all@FreeBSD.ORG Sat Mar 29 03:52:14 2014 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBC65626; Sat, 29 Mar 2014 03:52:14 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C469CDF9; Sat, 29 Mar 2014 03:52:14 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2T3qBEw044359; Sat, 29 Mar 2014 03:52:12 GMT (envelope-from davidxu@freebsd.org) Message-ID: <53364369.10500@freebsd.org> Date: Sat, 29 Mar 2014 11:52:09 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mateusz Guzik Subject: Re: svn commit: r263755 - head/sys/kern References: <53351627.9000703@freebsd.org> <201403281613.s2SGDKpk010871@gw.catspoiler.org> <20140329025602.GB29296@dft-labs.eu> <5336396E.7000801@freebsd.org> <20140329032513.GC29296@dft-labs.eu> In-Reply-To: <20140329032513.GC29296@dft-labs.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: src-committers@FreeBSD.org, mjg@FreeBSD.org, Don Lewis , svn-src-head@FreeBSD.org, kostikbel@gmail.com, svn-src-all@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 03:52:14 -0000 On 2014/03/29 11:25, Mateusz Guzik wrote: > On Sat, Mar 29, 2014 at 11:09:34AM +0800, David Xu wrote: >> On 2014/03/29 10:56, Mateusz Guzik wrote: >>> But this patch would mean that current consumers (if any) would break - >>> just calling FIOASYNC would not result in receiving SIGIO. >> The old behavior is inconsistent with other piece of code in the kernel and >> may be incompatible with POSIX. >> > Oh, I didn't know that. Unsure what to do in this case. > >>> Original patch by Don seems to work fine though, but I'm unsure about >>> one thing (present in this patch as well): >>> >>> There is one devsoftc.sigio instance and one can get multiple processes >>> with devctl fd. Is it safe from kernel perspective to have multiple >>> processes call fsetown(*(int *)data, &devsoftc.sigio)? >>> >> There is an inuse variable guarding this problem, you can not open it >> multiple times, you can only do it in the forked process which inherited >> the fd. if you don't trust the child process, you can close it before >> executing real code in the child process. >> > This does not answer my question. > > I can easily imagine devctl extended in the future so that there are > per-jail instances (could be handy to monitor e.g. vnet related events > like link changes). > > If fsetown handling like this is insecure this would bite us in that > scenario (and few others). In short, if we can avoid giving another way > to corrupt stuff in the kernel to userspace, we should. > I can not see what you said, where is the security problem with fsetown ? if you have per-jail instance of devsoftc, they all are operating on their own instance. but I don't think this patch should address jail now, there are many things are not jail ready.