# Shared memory in Jails



## Ben (May 2, 2013)

Hi,

To run PostgreSQL in a jail you need to set sysvipc_allow to 1. I don't know exactly what this setting means but I understand this allows the usage of shared memory in jails.

Now APC (PHP Opcode-Cache) uses shared memory for caching as well. Does this mean I have to set sysvipc_allow to 1 for my Webserver-Jail as well?

Thanks for helping me to understand the purpose of sysvipc_allow and why some applications need it.


----------



## SirDice (May 2, 2013)

When a process starts it is given it's own "memorymap". On 32 bit this is about 4GB. A process that tries to access another process's memory map will result in an "access violation" and the process will die. When two processes want to exchange data there are several options to chose from, one is so-called shared memory. That's a bit of memory that can be accessed by one or more other processes. Using that you can exchange data.

Things get a little hairy with jails though, the shared memory "trick" doesn't understand jails and will create memory maps in the same namespace. It's therefore possible for one process in one jail to access another process in another jail. Be very aware of this unintended interaction (which is why it's turned off by default). When you need shared memory and you care for security it's best to separate the two on different physical boxes.


----------



## Ben (May 2, 2013)

Thanks for clarifying this.

So setting sysvipc_allow to 1 for one jail means, that this jail can access the memorymap of another jail/other processes? But others can not, right?


----------



## SirDice (May 2, 2013)

If I recall correctly it's turned on or off for _all_ jails, not a single one.


----------



## Ben (May 2, 2013)

Hm, but with
`jail -m jid=20 sysvipc_allow=1` I specify the Jail-ID (JID), which is 20 in my example.


----------



## SirDice (May 2, 2013)

Yes, but it will set it for all jails, not just that one.


----------



## Ben (May 2, 2013)

Ok, but in this case the parameter is misleading.


----------



## kpa (May 2, 2013)

SirDice said:
			
		

> When a process starts it is given it's own "memorymap". On 32 bit this is about 4GB. A process that tries to access another process's memory map will result in an "access violation" and the process will die. When two processes want to exchange data there are several options to chose from, one is so-called shared memory. That's a bit of memory that can be accessed by one or more other processes. Using that you can exchange data.



A slight clarification is in place here. When a process is started it has its very own memory map like said but it is actually a completely private one. The full addressing range a process can address appears to be "owned" by the process. There is no way that one process can even try to access the memory owned by another process, a virtual address of (for example) 0x1000 in hexadecimal for one process means absolutely nothing in another process because they both have their very own ideas of the memory they are using. For one of the processes the address may contain executable code, in the other it may be unused and there for no physical memory page has been mapped to that virtual address.


----------



## SirDice (May 2, 2013)

Yes, you are absolutely correct.


----------



## Ben (May 2, 2013)

I will verify if all jails will have permission to access the shared memory in this case, but I worry you are right.


----------



## Crest (May 2, 2013)

Only the SysV IPC is not covered by jails. Their are other ways to create shared memory between unrelated processes e.g. mmap(). These work inside jails. SysV IPC has the advantage that it supports some meta operations that PostgreSQL uses to prevent two PostreSQL instances to be started using the same shared memory resulting it catastrophic data corruption. SysV IPC descriptors representing opened IPC handles providing exclusive open semantics. Mapped files would require additional locking through an additional API. Since SysV IPC shared memory is limited to a tiny subset of the available memory on many systems their are patches to allocate most shared memory with mmap(). This introduces new problems because the shared files might be wrote back and flushed from memory under memory pressure trashing the database throughput and latency without providing any feedback to the application while at least on FreeBSD SysV shared memory can be configured as wired memory starving at most everything else than the database.


----------



## Deleted member 10519 (May 4, 2013)

If you want to view System V interprocess communication facilities, run the ipcs() command. It will list message queues, shared memory, and semaphores.


----------

