From owner-freebsd-arch@FreeBSD.ORG Wed Jun 25 08:46:31 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E481837B401 for ; Wed, 25 Jun 2003 08:46:31 -0700 (PDT) Received: from demos.su (mx.demos.su [194.87.0.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id C57C743FD7 for ; Wed, 25 Jun 2003 08:46:29 -0700 (PDT) (envelope-from mitya@fling-wing.demos.su) Received: from [194.87.5.69] (HELO fling-wing.demos.su) by demos.su (CommuniGate Pro SMTP 4.1b7/D) with ESMTP-TLS id 78052741; Wed, 25 Jun 2003 19:46:28 +0400 Received: from fling-wing.demos.su (localhost [127.0.0.1]) by fling-wing.demos.su (8.12.9/8.12.6) with ESMTP id h5PFkS5R035903; Wed, 25 Jun 2003 19:46:28 +0400 (MSD) (envelope-from mitya@fling-wing.demos.su) Received: (from mitya@localhost) by fling-wing.demos.su (8.12.9/8.12.6/Submit) id h5PFkRxu035902; Wed, 25 Jun 2003 19:46:27 +0400 (MSD) Date: Wed, 25 Jun 2003 19:46:27 +0400 From: Dmitry Sivachenko To: Pawel Jakub Dawidek Message-ID: <20030625154627.GA35011@fling-wing.demos.su> References: <20030624164602.GW7587@garage.freebsd.pl> <20030625135106.GA19868@fling-wing.demos.su> <20030625140518.GA23435@fling-wing.demos.su> <20030625144849.GJ7587@garage.freebsd.pl> <20030625145233.GA28322@fling-wing.demos.su> <20030625150221.GL7587@garage.freebsd.pl> <20030625152119.GA31396@fling-wing.demos.su> <20030625153153.GO7587@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20030625153153.GO7587@garage.freebsd.pl> WWW-Home-Page: http://mitya.pp.ru/ X-PGP-Key: http://mitya.pp.ru/mitya.asc User-Agent: Mutt/1.5.4i cc: freebsd-arch@FreeBSD.org Subject: Re: Jailed sysvipc implementation. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 15:46:32 -0000 On Wed, Jun 25, 2003 at 05:31:53PM +0200, Pawel Jakub Dawidek wrote: > On Wed, Jun 25, 2003 at 07:21:19PM +0400, Dmitry Sivachenko wrote: > +> > +> > But you got still *one* memory zones for every jail and main host. > +> > +> > +> > +> Yes, that is exactly what I want. > +> > +> This is similar to separate IP stack for each jail: this is more powerful > +> > +> solution, but more expensive (uses more kernel memory). > +> > > +> > But note that my implementation allocates memory "on demand". > +> > +> This is part of the problem: with single memory zone for all jails, > +> less memory is allocated. With private memory zones, if m jails use IPC, > +> you need to allocate m*M kbytes (for some value of M you consider > +> sufficient for one jail). > +> > +> With one memory zone for all jails, it is enough to allocate N kbytes where > +> M < N < m*M, because every jail will not use all M kbytes at the same time. > > Of course, but please. We could start wondering if struct prison in every > ucred struct don't consume to much memory. Of course we allocate more memory, Common sence is your friend. > but if we want to run for example two instants of postgresql in two > diffrent jails? I propose to add additional checks for p->p_prison. If two different users (with different UIDs) can use IPC, then it is simple to allow processes from different jails to use it too (and do not interfere with each other). > > But ok, it will be good compromise to add sysctl security.jail.privipc IMHO. > So we could turn this feature on if it is needed. What is your opinion? > My point of view is that allowing jailed processes to safely use single memory zone is simple and sufficient solution.