Re: Jailed sysvipc implementation.

From: Pawel Jakub Dawidek (nick_at_garage.freebsd.pl)
Date: 06/25/03

  • Next message: Dmitry Sivachenko: "Re: Jailed sysvipc implementation." 
    Date: Wed, 25 Jun 2003 16:48:49 +0200
To: Dmitry Sivachenko <mitya@cavia.pp.ru>

    On Wed, Jun 25, 2003 at 06:05:18PM +0400, Dmitry Sivachenko wrote:
    +> > > Some time ago I've implemented private memory zones for IPC mechism.
    +> > > Every jail and main host got its own memory for IPC operations.
    +> > > It was implemented for FreeBSD 4.x. Avaliable at:
    +> > >
    +> > > http://garage.freebsd.pl/privipc.tbz
    +> > > http://garage.freebsd.pl/privipc.README
    +> >
    +> > I think it would be better to add checks to disallow the use of IPC
    +> > primitives created in one jail from another.
    +> > Thus we will avoid allocating separate segments of kernel memory for
    +> > each jail.
    +> >
    +> > It could be trivially achieved by adding another field to struct ipc_perm,
    +> > but Robert Watson said he knows another way of doing this without
    +> > breaking ABI (if I understood him right).
    +> >
    +>
    +> Please look at his patch:
    +>
    +> http://www.watson.org/~robert/freebsd/mac_sysvipc.diff
    +>
    +> It does slightly different things, but we could borrow from it.

    But you got still *one* memory zones for every jail and main host.
    And I want to separate them. 

    -- 
Pawel Jakub Dawidek                       pawel@dawidek.net
UNIX Systems Programmer/Administrator     http://garage.freebsd.pl
Am I Evil? Yes, I Am!                     http://cerber.sourceforge.net

  • Next message: Dmitry Sivachenko: "Re: Jailed sysvipc implementation."

    Relevant Pages

    • Re: Jailed sysvipc implementation.
      ... +>> But you got still *one* memory zones for every jail and main host. ... that will thell if we want separate IPC memory zones for this jail or not. ... +> Let's keep it a *light* virtual machine replacement, with single IP stack, ...
      (freebsd-arch)
    • Re: new feature: private IPC for every jail
      ... this approach looks easier than having a distinct name space associated with each prison and has the advantage of allowing non-jailed processes to manage jailed IPC. ... two jails, or even the host and a jail, will never receive an ID already ...
      (freebsd-current)
    • Re: new feature: private IPC for every jail
      ... this approach looks easier than having a distinct name space associated with each prison and has the advantage of allowing non-jailed processes to manage jailed IPC. ... two jails, or even the host and a jail, will never receive an ID already ...
      (freebsd-stable)
    • Re: new feature: private IPC for every jail
      ... What happens now, if I load ipc, start up postgresql and then try to unload ipc? ... There are two general ways to approach adding virtualization to the System V IPC name spaces: ... Key virtualization to the identity of the jail. ... This is a nice piece of behavior, as it means file system subsetting is a facility available to be used regardless of the use of jail, and avoids hard-coding jail instrumentation throughout the file system code. ...
      (freebsd-current)
    • Re: new feature: private IPC for every jail
      ... What happens now, if I load ipc, start up postgresql and then try to unload ipc? ... There are two general ways to approach adding virtualization to the System V IPC name spaces: ... Key virtualization to the identity of the jail. ... This is a nice piece of behavior, as it means file system subsetting is a facility available to be used regardless of the use of jail, and avoids hard-coding jail instrumentation throughout the file system code. ...
      (freebsd-stable)