From: Mischa Sandberg <mischa_sandberg@telus.net>
To: Stephen Frost <sfrost@snowman.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Marc G. Fournier <scrappy@hub.org>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [ADMIN] postgresql in FreeBSD jails: proposal
Date: Thu, 17 Jan 2008 14:52:03 -0800
Message-ID: <1200610323.478fdc131bb3a@webmail.telus.net> (raw)
In-Reply-To: <20080117143729.GR5031@tamriel.snowman.net>
References: <1200501702.478e33c61b74e@webmail.telus.net>
<fmmqfh$buq$3@news.hub.org>
<4089.1200550374@sss.pgh.pa.us>
<20080117143729.GR5031@tamriel.snowman.net>
Quoting Stephen Frost <sfrost@snowman.net>:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > "Marc G. Fournier" <scrappy@hub.org> writes:
> > > Easiest fix: change the UID of the user running the postmaster
> (ie. pgsql) so
> > > that each runs as a distinct UID (instead of distinct PGPORT) ...
> been doing
> > > this since moving to FreeBSD 6.x ... no patches required ...
> >
> > Sure, but in the spirit of "belt and suspenders too", I'd think
> that
> > doing that *and* something like Mischa's proposal wouldn't be bad.
>
> I agree that we should try to be careful about stepping on
> segments that might still be in use, but I would also discourage
> jail users from using the same uid for multiple PG clusters
> since the jail doesn't protect the shmem segment.
> We use seperate uids even w/ linux-vservers where shmem
> and everything *is* seperate, following the same
> 'belt and suspenders too' spirit for security.
Thanks for all the input. Fixing freebsd might get answered
on a different channel :-)
Unfortunately, different uid's is not even an option here;
but serious security in this sitch is not relevant, either.
We have a freebsd core guy here, and he says that there's no
pressing incentive for jails to handle sysv ipc, given mmap
and file locking :-( And given his other comments, I wouldn't
consider jails a "secure" environment, just a modest and
convenient way to emulate multiple machines with caveats.
.........................................................
So, given Tom's comment, that it's antisocial to zap a shm seg
that other processes have attached ...
I'm going to skip the kill(1,0) test and depend on nattch only,
with a function that PGSharedMemoryIsInUse() can also use.
(For a healthy server, nattch is never less than 2, right?)
If no unpleasant edge cases come out of this in our test
framework, I'd like to submit that as a patch.
Talked with our Linux guys about vserver, and they see no issues.
Mr. Solaris here is currently a long way ooto ... opinions?
Afaics the change in behaviour is, if a degraded server exited
with some backend hanging, the second server will create a new
segment after bumping the ipc key; if system shm limits do not
allow for two such shm segments, the second server will bail.
For production systems, ensuring no orphan shm segs
is not left to heuristic clean-up by server re-start.
Hope that makes sense for the generic Postgres world.
If anyone is interested in creating hung backends, you can
create a named pipe, and tell the server to COPY from it.
---
Engineers think that equations approximate reality.
Physicists think that reality approximates the equations.
Mathematicians never make the connection.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: mischa_sandberg@telus.net, sfrost@snowman.net, tgl@sss.pgh.pa.us, scrappy@hub.org, pgsql-hackers@postgreSQL.org
Subject: Re: [ADMIN] postgresql in FreeBSD jails: proposal
In-Reply-To: <1200610323.478fdc131bb3a@webmail.telus.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox