Re: postgresql in FreeBSD jails: proposal

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> I've got a couple of concerns about this-

> #1: Having the shared memory be global is a rather large problem when it
> comes to something like PG which can have a fair bit of data going
> through that area that could be sensitive.

Well, you'd have to talk to the FreeBSD kernel hackers about changing
that, but I imagine it's still true that userid permissions checking
applies. Whether to run the postmasters that are in different jails
under different userids is a separate questions.

> #3: At least in the linux-equivilant to jails (linux-vservers, imv
> anyway), they started w/o an init process and eventually decided it
> made sense to have one, so I'm not sure that this test will always
> work and the result might catch someone by suprise at some later
> date. Is there a better/more explicit test?

We could just leave out the kill(1,0) part. In fact I wonder whether
we shouldn't do something like this on all platforms not only FreeBSD.
Quite aside from any considerations of jails, it seems like a pretty
bad idea to try to zap a shmem segment that has any attached processes.

Consider a system that normally runs multiple postmasters, in which one
postmaster has died but left orphaned backends behind, and we are trying
to start an unrelated postmaster. The current code seems capable of
deciding to zap the segment with those orphaned backends attached.
This'd require a shmem key collision which seems pretty improbable given
our key assignments, but not quite impossible. If it did happen then
the net effect would be to clear the segment's ID (since it can't
actually go away till the connected processes do). The bad thing about
that is that if the dead postmaster were then restarted, it wouldn't
recognize the segment as being its own, and would happily start up
despite the orphaned backends. Result: exactly the kind of conflicts
and data corruption that all these interlocks are trying to prevent.

So unless I'm missing something here, adding a check for nattch = 0
is a good idea, quite aside from making FreeBSD jails safer.

I think the worrisome question that follows on from Stephen's is really
whether FreeBSD will ever decide to lie about nattch (ie, exclude
processes in other jails from that count).

regards, tom lane