Date: Sat, 29 Mar 2014 11:52:09 +0800 From: David Xu <davidxu@freebsd.org> To: Mateusz Guzik <mjguzik@gmail.com> Cc: src-committers@FreeBSD.org, mjg@FreeBSD.org, Don Lewis <truckman@FreeBSD.org>, svn-src-head@FreeBSD.org, kostikbel@gmail.com, svn-src-all@FreeBSD.org Subject: Re: svn commit: r263755 - head/sys/kern Message-ID: <53364369.10500@freebsd.org> In-Reply-To: <20140329032513.GC29296@dft-labs.eu> References: <53351627.9000703@freebsd.org> <201403281613.s2SGDKpk010871@gw.catspoiler.org> <20140329025602.GB29296@dft-labs.eu> <5336396E.7000801@freebsd.org> <20140329032513.GC29296@dft-labs.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53364369.10500>