Re: semaphore usage "port based"?

On Mon, 3 Apr 2006, Tom Lane wrote:

> Robert Watson <rwatson@FreeBSD.org> writes:
>> Any multi-instance application that uses unvirtualized System V IPC must know
>> how to distinguish between those instances.
>
> Sure.
>
>> How is PostgreSQL deciding what semaphores to use?  Can it be instructed to
>> use non-colliding ones by specifying an alternative argument to pass to
>> ftok(), or ID to use directly?
>
> The problem here is not that we don't know how to avoid a collision. The 
> problem is stemming from code that we added to prevent semaphore leakage 
> during failure recoveries.  The code believes that it is deleting a 
> semaphore set left over from a crashed previous instance of the same 
> postmaster.
>
> 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.

I guess what I'm saying is this: by turning on system V IPC in a jail, 
administrators accept that they are using an unsupported configuration, in 
which the security features of jail, which include hiding the process state of 
other jails, are known to conflict with the System V IPC services.  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.  If it is turned on for 
more than one jail, then isolation is not provided for System V IPC.

So my recommendation is, if people want to run Postgres in more than one jail 
at a time, they be provided with a configuration option to disambiguate which 
semaphore to use: they must hard-code that it will not use the same sempahore 
already in use by another Postgres instance in another Jail.  This is no 
different than specifying that if there are multiple Apache's running on a 
single system, that they run on different port/IP combinations.  If they 
aren't configured to do so, one of them will encounter an error when running, 
because the resource is already in use, and you may get unpredictable results 
if the two Apaches are started at the same time, restarted, etc, as they will 
race to acquire the resource.

Whether you pull the resource ID out of a hat, use ftok(), or whatever, I 
really mind, and have no strong opinion.  The name space of System V IPC is 
one of the known problems with the IPC model, and sadly, one accepts those 
problems by using those IPC mechanisms.

Robert N M Watson