Re: Jailed sysvipc implementation.
From: Dmitry Sivachenko (demon_at_freebsd.org)
Date: 06/25/03
- Previous message: Pawel Jakub Dawidek: "Re: Jailed sysvipc implementation."
- In reply to: Pawel Jakub Dawidek: "Jailed sysvipc implementation."
- Next in thread: Pawel Jakub Dawidek: "Re: Jailed sysvipc implementation."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 25 Jun 2003 17:51:06 +0400 To: Pawel Jakub Dawidek <nick@garage.freebsd.pl>
On Tue, Jun 24, 2003 at 06:46:02PM +0200, Pawel Jakub Dawidek wrote:
> Hello.
>
> 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).
- application/pgp-signature attachment: stored
- Previous message: Pawel Jakub Dawidek: "Re: Jailed sysvipc implementation."
- In reply to: Pawel Jakub Dawidek: "Jailed sysvipc implementation."
- Next in thread: Pawel Jakub Dawidek: "Re: Jailed sysvipc implementation."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
- Re: Jailed sysvipc implementation.
... +>> Some time ago I've implemented private memory zones for IPC mechism.
... +>> Every jail and main host got its own memory for IPC operations. ...
I implemented something like allocate-on-demand. ... (freebsd-arch) - 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) - Re: [HACKERS] semaphore usage "port based"?
... We don't use ftok() to determine the keys, and I'm disinclined to think that doing
so would improve the situation: you could still have key collisions, they'd just be unpredictable and
there'd be no convenient mechanism for escaping one if you hit it. ... We specifically disable
System V IPC in jails because it is known to have undesirable properties. ... When configuring
systems in that state, the responsibility falls on the administrator to disambiguate the configuration
by specifying which resources must be used in order to prevent a conflict, because software operating
in that environment will not be able to do so properly. ... The goal of the switch to enable System
V IPC is to allow IPC to be enabled for a single jail at a time, where it can be used to its full
capabilities, without violating the security model. ... (freebsd-stable) - Re: Shared Memory for Application/Communication decoupling
... different IPC methods within a single task will introduce a lot of ... memory
techniques are just a nice way of saying 'global data'. ... A messaging based
interface is generally more elegant and arguably more ... (comp.arch.embedded)
