Date: Sat, 29 Mar 2014 05:14:41 +0100 From: Mateusz Guzik <mjguzik@gmail.com> To: David Xu <davidxu@freebsd.org> 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: <20140329041441.GD29296@dft-labs.eu> In-Reply-To: <53364369.10500@freebsd.org> References: <53351627.9000703@freebsd.org> <201403281613.s2SGDKpk010871@gw.catspoiler.org> <20140329025602.GB29296@dft-labs.eu> <5336396E.7000801@freebsd.org> <20140329032513.GC29296@dft-labs.eu> <53364369.10500@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 29, 2014 at 11:52:09AM +0800, David Xu wrote: > >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. > I asked if multpiple concurrent calls to fsetown(.., &pointer) could result in some corruption in the kernel - if they could, we would have a problem in the future. I decided to read the code once more and fsetown seems to be safe in this regard after all and with that in mind the patch looks good to me. This thread is too long already, so I'm stepping down on this one in case there are some futher concerns. -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140329041441.GD29296>