Re: semaphore usage "port based"?

On Mon, 3 Apr 2006, Tom Lane wrote:

> Robert Watson <rwatson(at)FreeBSD(dot)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