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.
> 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 :-).
Postgres is absolutely designed not to walk all over itself. It is,
however, designed to clean up after itself, and I don't consider that a
bug. The problem here is that by redefining the behavior of kill, you've
prevented the code from detecting the existence of the other postmaster,
and thereby triggered the cleanup behavior.
I don't exactly see why it's considered such a critical security feature
that kill return ESRCH rather than, say, EPERM for processes in another
jail. kill won't tell you what that process is or what it's doing,
so the amount of information leaked is certainly pretty trivial. It'd
be fine if FBSD actually had a jail implementation that leaked zero
information, but you don't --- in fact, you're saying it's a feature
that you don't.
Perhaps a reasonable compromise would be to have the
SysV-IPC-allowed-in-jails switch also restore the normal return value
of kill(). This seems sensible to me because the GETPID feature makes
PIDs be part of the API that is exposed across jails.
regards, tom lane
