[HACKERS] semaphore usage "port based"?

[Robert Watson]

On Mon, 3 Apr 2006, Tom Lane wrote:

> Robert Watson <rwatson at FreeBSD.org> writes:
>> Maybe I've misunderstood the problem here -- is the use of the GETPID
>> operation occuring within a coordinated set of server processes, or does it
>> also occur between client and server processes?  I think it's quite reasonable
>> to argue that a coordinated set of server processes should be able to see each
>> other, especially if they're running as the same user, in the same jail,
>> started at the same time.
>
> We use the semaphore sets only within postgres server processes; we could 
> hardly expect client processes to be able to get at them, since in general 
> clients aren't on the same machine.  The issue here, though, is that Marc is 
> trying to start multiple postgres servers in different jails, and in that 
> context the different postgres servers aren't "coordinated" in any real 
> sense.  We'd prefer that they didn't interact at all, but they are 
> interacting because the SysV code isn't restricting IPC to occur only within 
> a jail.
>
> BTW, Marc, it occurs to me that a workaround for you would be to create a 
> separate userid for postgres to run under in each jail; then the regular 
> protection mechanisms would prevent the different postmasters from 
> interfering with each others' semaphore sets.  But I think that workaround 
> just makes it even clearer that the jail mechanism isn't behaving very 
> sanely.

Any multi-instance application that uses unvirtualized System V IPC must know 
how to distinguish between those instances.  This is true of any potential 
communication mechanism used by multi-instance applications -- be it a command 
line argument to specify an alternative configuration file, or a configuration 
file that specifies alternative ports, working directories, mail spool 
directories, etc.  If you install two instances of sendmail, it requires some 
configuration to teach them not to step all over each other, and this is not 
an accident: if they try to use the same mail spools, ports, etc, things will 
go badly.  I can't imagine that PostgreSQL should be any different -- it has 
to be pointed at what resources to use and how to use them -- some of that 
will be a property of how it's written, and some how it's configured. 
Presumably, running multiple instances of PostgreSQL in jails should not be 
all that different from running multiple instances on any UNIX machine: they 
must not overlap where shared resources are concerned.

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?

>> I would, in general, consider the use of System V IPC across jails (as 
>> opposed to in a single jail) unsupported, since it's not consistent with 
>> the security model.
>
> That'd be fine with me --- the problem here is that we've got unwanted 
> communication across jails.  If, say, the jail ID were considered part of 
> semaphore keys, we'd be in fine shape.

Well, I think it's definitely unwanted communications, but until such time as 
FreeBSD supports virtualizing the System V IPC name spaces, the fact that you 
can communicate between jails when System V IPC support is turned on for the 
jail shouldn't be a surprise, and should in fact be considered a feature. 
However, if applications behave incorrectly when treading over each other 
because either they aren't written to support specifying how not to walk over 
each other, or if they are not configured to use that support, then they're 
not going to behave well :-).

Robert N M Watson