On Tue, 9 May 2006, Max Khon wrote:
Yes, there seems to be an awful lot of noise being made about the fact that
the system does, in fact, work exactly as documented, and that the
configuration being complained about is one that is specifically documented
as being unsupported and undesirable.
Hi!
On Mon, Apr 03, 2006 at 11:56:13PM +0100, Robert Watson wrote:
> >>This is why it's disabled by default, and the jail documentation
> >>specifically advises of this possibility. Excerpt below.
> >
> >Ah, I see, glad to see it's accurately documented.
>
> As it has been for the last five ye
On Tue, 4 Apr 2006, Peter Jeremy wrote:
On Mon, 2006-Apr-03 14:55:10 -0300, Marc G. Fournier wrote:
That is all I'm advocatin / asking for ... some way of reverting kill(PID,
0) back to the old, FreeBSD 4.x behaviour, where this works beautifully :(
At least until someone does get around to 'vi
On Tue, Apr 04, 2006 at 10:17:18AM -0400, Vivek Khera wrote:
> Perhaps you can hack into the postgresql master a flag that alters
> the "1000" parameter, or starts at a port * 1000 + N, then hard-code
> that flag into your startup script per jail.
A quick and dirty hack to fudge with the reque
On Apr 3, 2006, at 8:07 PM, Marc G. Fournier wrote:
All PostgreSQL processes use "port * 1000" as their starting port
for semId ... if "port * 1000" is reported as in use, the first
thing that the PostgreSQL process does is kill(PID, 0) the PID
returned by semctl(GETPID) to see if, in fact
On Apr 3, 2006, at 3:41 PM, Daniel Eischen wrote:
... and you *still* haven't shown *why* kill() reporting a PID is
in use,
even if its not in the current jail, is such a security threat ...
For reducing attacks I suppose. But conceptually, something running
in a jail shouldn't be allowed
On Mon, 2006-Apr-03 14:55:10 -0300, Marc G. Fournier wrote:
>That is all I'm advocatin / asking for ... some way of reverting kill(PID,
>0) back to the old, FreeBSD 4.x behaviour, where this works beautifully :(
>At least until someone does get around to 'virtualization of SysV IPC' :(
There's t
* Marc G. Fournier ([EMAIL PROTECTED]) wrote:
> On Mon, 3 Apr 2006, Stephen Frost wrote:
> >Running the Postgres instances under different uids (as you'd probably
> >expect to do anyway if not using the jails) is probably the right
> >approach. Doing that and using jails would probably work, just
On Mon, 3 Apr 2006, Robert Watson wrote:
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
The problem here is actually that two postgres instances are trying to use
the same sempahore when they are actually different postgres instances.
No, the problem here is that kill(PID, 0) reports that a PI
On Mon, 3 Apr 2006, Stephen Frost wrote:
* Robert Watson ([EMAIL PROTECTED]) wrote:
On Mon, 3 Apr 2006, Stephen Frost wrote:
This is certainly a problem with FBSD jails... Not only the
inconsistancy, but what happens if someone manages to get access to the
appropriate uid under one jail and s
yOn Mon, 3 Apr 2006, Robert Watson wrote:
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
This falls under "well,we broke kill() so that it now reports a PID is not
in use even though it is, so its has to be the application that fixes it"
... and you *still* haven't shown *why* kill() reporting
On Mon, Apr 03, 2006 at 06:51:45PM -0400, Stephen Frost wrote:
> * Robert Watson ([EMAIL PROTECTED]) wrote:
> > On Mon, 3 Apr 2006, Stephen Frost wrote:
> > >This is certainly a problem with FBSD jails... Not only the
> > >inconsistancy, but what happens if someone manages to get access to the
>
On Mon, 3 Apr 2006, Stephen Frost wrote:
This is why it's disabled by default, and the jail documentation
specifically advises of this possibility. Excerpt below.
Ah, I see, glad to see it's accurately documented.
As it has been for the last five years, I believe since introduction of the
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
This falls under "well,we broke kill() so that it now reports a PID is not
in use even though it is, so its has to be the application that fixes it"
... and you *still* haven't shown *why* kill() reporting a PID is in use,
even if its not in the cur
* Robert Watson ([EMAIL PROTECTED]) wrote:
> On Mon, 3 Apr 2006, Stephen Frost wrote:
> >This is certainly a problem with FBSD jails... Not only the
> >inconsistancy, but what happens if someone manages to get access to the
> >appropriate uid under one jail and starts sniffing or messing with th
On Mon, 3 Apr 2006, Tom Lane wrote:
BTW, as long as we're annoying the freebsd-stable list with discussions of
workarounds, I'm wondering whether our shared memory code might have similar
risks. Does FBSD 6 also lie about the existence of other-jail processes
connected to a shared memory seg
On Mon, 3 Apr 2006, Stephen Frost wrote:
So I think the code is pretty bulletproof as long as it's in a system that
is behaving per SysV spec. The problem in the current FBSD situation is
that the jail mechanism is exposing semaphore sets across jails, but not
exposing the existence of the o
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
Does PGSQL have a way to specify the semaphore ID to use?
Yes, changing the port # that the server responds on ...
So if you use that setting, do things work as desired? If not, then that's
what we should be debugging.
Robert N M Watson
__
On Mon, 3 Apr 2006, Tom Lane wrote:
Robert Watson <[EMAIL PROTECTED]> 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-
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
The problem here is actually that two postgres instances are trying to use
the same sempahore when they are actually different postgres instances.
No, the problem here is that kill(PID, 0) reports that a PID is 'not in use'
when, in fact, it is, bu
Stephen Frost <[EMAIL PROTECTED]> writes:
> Could this be handled sensibly by using SEM_UNDO? Just a thought.
Interesting thought, but I think it doesn't work for the special case
where the semaphore's "previous owner" is actually our same PID ---
which is actually the more commonly exercised pat
* Tom Lane ([EMAIL PROTECTED]) wrote:
> BTW, Marc, it occurs to me that a workaround for you would be to create
> a separate userid for postgres to run under in each jail; then the
> regular protection mechanisms would prevent the different postmasters
> from interfering with each others' semaphore
On Mon, Apr 03, 2006 at 03:42:51PM -0400, Stephen Frost wrote:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
> > That's a fair question, but in the context of the code I believe we are
> > behaving reasonably. The reason this code exists is to provide some
> > insurance against leaking semaphores when a
* Tom Lane ([EMAIL PROTECTED]) wrote:
> That's a fair question, but in the context of the code I believe we are
> behaving reasonably. The reason this code exists is to provide some
> insurance against leaking semaphores when a postmaster process is
> terminated unexpectedly (ye olde often-recomme
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
> On Mon, 3 Apr 2006, Daniel Eischen wrote:
>
> >
> > Or:
> >
> > 3) Run postgres in such a way that it doesn't look for
> > remnant IPC information from other instances (use a
> > per-jail-specific port #?).
> >
> > Postgres has no business cle
On Mon, 3 Apr 2006, Daniel Eischen wrote:
On Tue, 4 Apr 2006, Peter Jeremy wrote:
On Mon, 2006-Apr-03 08:19:00 -0400, Daniel Eischen wrote:
I don't really see what the problem is. ESRCH seems perfectly
reasonable for trying to kill (even sig 0) a process from a
different jail. If you're in
On Tue, 4 Apr 2006, Peter Jeremy wrote:
On Mon, 2006-Apr-03 08:19:00 -0400, Daniel Eischen wrote:
I don't really see what the problem is. ESRCH seems perfectly
reasonable for trying to kill (even sig 0) a process from a
different jail. If you're in a jail, then you shouldn't have
knowledge of
On Tue, 4 Apr 2006, Peter Jeremy wrote:
> On Mon, 2006-Apr-03 08:19:00 -0400, Daniel Eischen wrote:
> >I don't really see what the problem is. ESRCH seems perfectly
> >reasonable for trying to kill (even sig 0) a process from a
> >different jail. If you're in a jail, then you shouldn't have
> >k
On Mon, 2006-Apr-03 08:19:00 -0400, Daniel Eischen wrote:
>I don't really see what the problem is. ESRCH seems perfectly
>reasonable for trying to kill (even sig 0) a process from a
>different jail. If you're in a jail, then you shouldn't have
>knowledge of processes from other jails.
I agree in
On Apr 3, 2006, at 12:37 PM, Tom Lane wrote:
semaphore keys on each cycle of life, so you'd have to get fooled by
chance coincidence of existing PIDs every time over many cycles to
have a severe resource-leakage problem. (BTW, Marc, that's the reason
for *not* randomizing the key selection as
On Mon, 3 Apr 2006, Robert Watson wrote:
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
The problem is that PostgreSQL uses kill(PID, 0) to determine whether or
not another process is running when it tries to allocate a semaphore ...
for instance, when it starts up, it tries to semget(54320001
Robert Watson <[EMAIL PROTECTED]> 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 al
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
The problem is that PostgreSQL uses kill(PID, 0) to determine whether or not
another process is running when it tries to allocate a semaphore ...
for instance, when it starts up, it tries to semget(54320001); ... if that
fails, based on the PID tha
On Mon, 3 Apr 2006, Tom Lane wrote:
Robert Watson <[EMAIL PROTECTED]> writes:
Maybe I've misunderstood the problem here -- is the use of the GETPID
operation occuring within a coordinated set of server processes, or does it
also occur between client and server processes? I think it's quite rea
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
> On Mon, 3 Apr 2006, Daniel Eischen wrote:
>
> >> I think the suggestion was to make this EPERM rather than ESRCH to make
> >> postgres a bit happier, not remove the check entirely. Im not familiar
> >> with that part of the kernel at all, so I cant say
On Mon, 3 Apr 2006, Daniel Eischen wrote:
On Mon, 3 Apr 2006, Andrew Thompson wrote:
On Mon, Apr 03, 2006 at 01:23:59AM -0300, Marc G. Fournier wrote:
taking it off of pgsql-hackers, so that we don't annoy them unnecessarily
...
'k, looking at the code, not that most of it doesn't go over m
Robert Watson <[EMAIL PROTECTED]> writes:
> Maybe I've misunderstood the problem here -- is the use of the GETPID
> operation occuring within a coordinated set of server processes, or does it
> also occur between client and server processes? I think it's quite
> reasonable
> to argue that a co
On Mon, 3 Apr 2006, Tom Lane wrote:
That's a fair question, but in the context of the code I believe we are
behaving reasonably. The reason this code exists is to provide some
insurance against leaking semaphores when a postmaster process is terminated
unexpectedly (ye olde often-recommended
Robert Watson <[EMAIL PROTECTED]> writes:
> However, pid's in general uniquely identify a process only at the time they
> are recorded. So any pid returned here is necessarily stale -- even if there
> is another process with the pid returned by GETPID, it may actually be a
> different process th
On Sun, 2 Apr 2006, Tom Lane wrote:
Oops. Here is the problem: kill() is lying by claiming there is no such
process as 83699. It looks to me like there in fact is such a process, but
it's in a different jail.
I venture that FBSD 6 has decided to return ESRCH (no such process) where
FBSD 4
On Mon, 3 Apr 2006, Andrew Thompson wrote:
> On Mon, Apr 03, 2006 at 01:23:59AM -0300, Marc G. Fournier wrote:
> >
> > taking it off of pgsql-hackers, so that we don't annoy them unnecessarily
> > ...
> >
> > 'k, looking at the code, not that most of it doesn't go over my head ...
> > but ...
> >
On Mon, 3 Apr 2006, Andrew Thompson wrote:
On Mon, Apr 03, 2006 at 01:57:17AM -0300, Marc G. Fournier wrote:
On Mon, 3 Apr 2006, Andrew Thompson wrote:
On Mon, Apr 03, 2006 at 01:23:59AM -0300, Marc G. Fournier wrote:
in kern/kern_jail.c, I can see the prison_check() call ... wouldn't one
w
On Mon, Apr 03, 2006 at 01:57:17AM -0300, Marc G. Fournier wrote:
> On Mon, 3 Apr 2006, Andrew Thompson wrote:
>
> >On Mon, Apr 03, 2006 at 01:23:59AM -0300, Marc G. Fournier wrote:
> >>
> >>in kern/kern_jail.c, I can see the prison_check() call ... wouldn't one
> >>want to make the change a bit f
On Mon, 3 Apr 2006, Andrew Thompson wrote:
On Mon, Apr 03, 2006 at 01:23:59AM -0300, Marc G. Fournier wrote:
taking it off of pgsql-hackers, so that we don't annoy them unnecessarily
...
'k, looking at the code, not that most of it doesn't go over my head ...
but ...
in kern/kern_jail.c, I c
On Mon, Apr 03, 2006 at 01:23:59AM -0300, Marc G. Fournier wrote:
>
> taking it off of pgsql-hackers, so that we don't annoy them unnecessarily
> ...
>
> 'k, looking at the code, not that most of it doesn't go over my head ...
> but ...
>
> in kern/kern_jail.c, I can see the prison_check() cal
taking it off of pgsql-hackers, so that we don't annoy them unnecessarily
...
'k, looking at the code, not that most of it doesn't go over my head ...
but ...
in kern/kern_jail.c, I can see the prison_check() call ... wouldn't one
want to make the change a bit further up? say in kern_prot
On Sun, Apr 02, 2006 at 11:41:01PM -0400, Kris Kennaway wrote:
> On Mon, Apr 03, 2006 at 12:30:58AM -0300, Marc G. Fournier wrote:
> > 'k, but how do I fix kill so that it has the proper behaviour if SysV is
> > enabled?
>
> Check the source, perhaps there's already a way. If not, talk to
> whoe
On Mon, Apr 03, 2006 at 12:30:58AM -0300, Marc G. Fournier wrote:
> On Sun, 2 Apr 2006, Kris Kennaway wrote:
>
> >On Sun, Apr 02, 2006 at 11:17:49PM -0400, Tom Lane wrote:
> >>Kris Kennaway <[EMAIL PROTECTED]> writes:
> >>>On Sun, Apr 02, 2006 at 11:08:11PM -0400, Tom Lane wrote:
> If this is
On Sun, 2 Apr 2006, Kris Kennaway wrote:
No-one is taking a position of being "uninterested", so please don't
be hasty to reciprocate.
I just posted it off the -hackers list, but there is an ancient patch in
the FreeBSD queue for implementing Private IPCs for Jails ... not sure why
it was ne
On Sun, Apr 02, 2006 at 11:26:52PM -0400, Tom Lane wrote:
> Kris Kennaway <[EMAIL PROTECTED]> writes:
> > On Sun, Apr 02, 2006 at 11:17:49PM -0400, Tom Lane wrote:
> >> I have no objection to doing that, so long as you are actually doing it
> >> correctly. This example shows that each jail must ha
On Sun, 2 Apr 2006, Kris Kennaway wrote:
On Sun, Apr 02, 2006 at 11:17:49PM -0400, Tom Lane wrote:
Kris Kennaway <[EMAIL PROTECTED]> writes:
On Sun, Apr 02, 2006 at 11:08:11PM -0400, Tom Lane wrote:
If this is the story, then FBSD have broken their system and must revert
their change. They d
Kris Kennaway <[EMAIL PROTECTED]> writes:
> On Sun, Apr 02, 2006 at 11:17:49PM -0400, Tom Lane wrote:
>> I have no objection to doing that, so long as you are actually doing it
>> correctly. This example shows that each jail must have its own SysV
>> semaphore key space, else information leaks any
On Sun, Apr 02, 2006 at 11:17:49PM -0400, Tom Lane wrote:
> Kris Kennaway <[EMAIL PROTECTED]> writes:
> > On Sun, Apr 02, 2006 at 11:08:11PM -0400, Tom Lane wrote:
> >> If this is the story, then FBSD have broken their system and must revert
> >> their change. They do not have kernel behavior that
Kris Kennaway <[EMAIL PROTECTED]> writes:
> On Sun, Apr 02, 2006 at 11:08:11PM -0400, Tom Lane wrote:
>> If this is the story, then FBSD have broken their system and must revert
>> their change. They do not have kernel behavior that totally hides the
>> existence of the other process, and therefor
On Sun, Apr 02, 2006 at 11:08:11PM -0400, Tom Lane wrote:
> I venture that FBSD 6 has decided to return ESRCH (no such process)
> where FBSD 4 returned some other error that acknowledged that the
> process did exist (EPERM would be a reasonable guess).
>
> If this is the story, then FBSD have bro
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> 'k, try this one ... looks better, actually has semget() calls in it :)
OK, here's our problem:
84250: semget(0x52e2c1,0x11,0x780) ERR#17 'File exists'
This is InternalIpcSemaphoreCreate failing because of key collision.
As it should
Sent offlist ...
On Sun, 2 Apr 2006, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
On Sun, 2 Apr 2006, Tom Lane wrote:
OK, could we see strace (or whatever BSD calls it) output for the second
postmaster? I'd like to see exactly what results it's getting for the
kernel calls
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Sun, 2 Apr 2006, Tom Lane wrote:
>> OK, could we see strace (or whatever BSD calls it) output for the second
>> postmaster? I'd like to see exactly what results it's getting for the
>> kernel calls it makes during IpcSemaphoreCreate.
> 'k, dont'
On Sun, 2 Apr 2006, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
On Sun, 2 Apr 2006, Tom Lane wrote:
BTW, even before doing that, you should look at "ipcs -s" output to try
to get a clue what's going on. The EINVAL failures may be because the
second postmaster to start delet
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Sun, 2 Apr 2006, Tom Lane wrote:
>> BTW, even before doing that, you should look at "ipcs -s" output to try
>> to get a clue what's going on. The EINVAL failures may be because the
>> second postmaster to start deletes the semaphores created by
On Sun, 2 Apr 2006, Tom Lane wrote:
I wrote:
Look at IpcSemaphoreCreate and InternalIpcSemaphoreCreate in
src/backend/port/sysv_sema.c. It may be worth stepping through them
with gdb to see what the semget calls are returning.
BTW, even before doing that, you should look at "ipcs -s" output
61 matches
Mail list logo