Re: postgresql in FreeBSD jails: proposal

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Mischa Sandberg <mischa_sandberg(at)telus(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: postgresql in FreeBSD jails: proposal
Date: 2008-01-16 20:51:16
Message-ID: 27984.1200516676@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-bugs pgsql-committers pgsql-general pgsql-hackers pgsql-jdbc pgsql-odbc pgsql-patches

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

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Marc G. Fournier 2008-01-17 05:52:50 Re: postgresql in FreeBSD jails: proposal
Previous Message Jan de Visser 2008-01-16 19:06:32 Re: trying to connect to pg from within a local network

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2008-01-16 21:01:00 Re: BUG #3879: OS X Start Script should not `cd /Users/postgres`
Previous Message Stephen Frost 2008-01-16 17:50:41 Re: postgresql in FreeBSD jails: proposal

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2008-01-17 01:19:27 Proposed patch for renaming constraints along with indexes
Previous Message Stephen Frost 2008-01-16 17:50:41 Re: postgresql in FreeBSD jails: proposal

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2008-01-16 20:52:56 Re: Some ideas about Vacuum
Previous Message Andrew Dunstan 2008-01-16 20:46:25 Re: COPY encoding

Browse pgsql-admin by date

  From Date Subject
Next Message Ivo Rossacher 2008-01-16 22:32:17 Re: Strange client encoding issue
Previous Message Benjamin Krajmalnik 2008-01-16 20:30:42 Strange client encoding issue

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2008-01-16 21:00:25 pgsql: Remove inappropriate cd commands, per David Wheeler.
Previous Message Bruce Momjian 2008-01-16 20:13:44 pgsql: Improve usage message for pgindent.

Browse pgsql-odbc by date

  From Date Subject
Next Message Ivo Rossacher 2008-01-16 22:32:17 Re: Strange client encoding issue
Previous Message Benjamin Krajmalnik 2008-01-16 20:30:42 Strange client encoding issue

Browse pgsql-general by date

  From Date Subject
Next Message dvanatta 2008-01-16 21:23:35 Re: Sun acquires MySQL
Previous Message Rajarshi Guha 2008-01-16 20:43:56 Re: PL/pgsql function handle CUBE values