Robert Watson <rwatson@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.
> 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.
regards, tom lane
