Date: Mon, 15 Jun 2015 12:49:16 +0200 From: Mateusz Guzik <mjguzik@gmail.com> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: kikuchan@uranus.dti.ne.jp, freebsd-jail@freebsd.org, freebsd-virtualization@freebsd.org Subject: Re: How to implement jail-aware SysV IPC (with my nasty patch) Message-ID: <20150615104915.GA18004@dft-labs.eu> In-Reply-To: <2B7AA933-CB74-4737-8330-6E623A31C6DA@lists.zabbadoz.net> References: <cc18282ebe394476120a139239225782@imap.cm.dream.jp> <2B7AA933-CB74-4737-8330-6E623A31C6DA@lists.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 15, 2015 at 09:53:53AM +0000, Bjoern A. Zeeb wrote: > Hi, > > removed hackers, added virtualization. > > > > On 12 Jun 2015, at 01:17 , kikuchan@uranus.dti.ne.jp wrote: > > > > Hello, > > > > I’m (still) trying to figure out how jail-aware SysV IPC mechanism should be. > > The best way probably is to finally get the “common” VIMAGE framework into HEAD to allow easy virtualisation of other services. That work has been sitting in perforce for a few years and simply needs updating for sysctls I think. > > Then use that to virtualise things and have a vipc like we have vnets. The good news is that you have identified most places and have the cleanup functions already so it’d be a matter of transforming your changes (assuming they are correct and working fine; haven’t actually read the patch in detail;-) to the different infrastructure. And that’s the easiest part. > > I have not looked at vimage too closely, maybe indeed it's the right to go. Would definitely be interested in seeing it cleaned up and in action. In the meantime, as I tried to explain in the previous thread, a jail-aware sysvshm poses several questions which need to be answered/taken care of before it can hit the tree. I doubt any reasonable implementation can magically avoid problems they pose and I definitely want to get an analysis how proposed implementation behaves (or how it prevents given scenario from occuring). Fundamentally the basic question is how does the implementation cope with processes having sysvshm mappings obtained from 2 different jails (provided they use different sysvshms). Preferably the whole business would be /prevented/. Prevention mechanism would have to deal with shared address spaces (rfork(2) + RFMEM), threads and pre-existing mappings. The patch posted here just puts permission checks in several places, while leaving the namespace shared, which I find to be a user-visible hack with no good justification. There is also no analysis how this behaves when presented with aforementioned scenario. Even if it turns out the resut is harmless with resulting code, this leaves us with a very error-prone scheme. There is no technical problem adding a pointer to struct prison and dereferencing it instead of current global vars. Adding proper sysctls dumping the content for given jail is trivial and so is providing resource limits when creating a first-level jail with a separate sysvshm. Something which cannot be as easily achieved with the patch in question. Possible later switch to vimage would be transparent to users. -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150615104915.GA18004>