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 years, I
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 the
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 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 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 requested
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
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
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
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
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
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 that
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
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
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 what the
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
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
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
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
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 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
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
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 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 cleaning up after
* 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
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:
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
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 path,
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,
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
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, 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
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
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
* 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 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, 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
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 a
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
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
* 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 don't
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
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 the first
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 deletes
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' know what
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 it
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.
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 broken
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 therefore having
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 totally
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 anyway.
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 do
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 have its own
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
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 the story, then
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
whoever
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
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() call ...
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
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 further up?
61 matches
Mail list logo
