Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-bugspgsql-committerspgsql-generalpgsql-hackerspgsql-jdbcpgsql-odbcpgsql-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

pgsql-odbc by date

Next:From: Ivo RossacherDate: 2008-01-16 22:32:17
Subject: Re: Strange client encoding issue
Previous:From: Benjamin KrajmalnikDate: 2008-01-16 20:30:42
Subject: Strange client encoding issue

pgsql-patches by date

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

pgsql-admin by date

Next:From: Ivo RossacherDate: 2008-01-16 22:32:17
Subject: Re: Strange client encoding issue
Previous:From: Benjamin KrajmalnikDate: 2008-01-16 20:30:42
Subject: Strange client encoding issue

pgsql-bugs by date

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

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2008-01-16 20:52:56
Subject: Re: Some ideas about Vacuum
Previous:From: Andrew DunstanDate: 2008-01-16 20:46:25
Subject: Re: COPY encoding

pgsql-committers by date

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

pgsql-general by date

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

pgsql-jdbc by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group