Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am confused because you say dangling then you say to the real
socket. You are saying it isn't dangling when the server is running?
Exactly. When the server is running it provides a perfectly good path
to the postmaster. The
On Thu, 17 Jan 2008, Tom Lane wrote:
BTW, is a symlink's atime changed by accessing it?
It seems so in the cases I've tried or researched, but it's complicated.
After burning through a bunch of time looking into this I wanted to drop
some notes so nobody else has to wander down the specific
Am Donnerstag, 17. Januar 2008 schrieb Andrew Dunstan:
I agree. I remain of the opinion that this is not a problem than can be
solved purely within the bounds of postgres.
Well, the SSL patch I showed certainly solves the problem. (I am not saying
it is the best possible solution.) Of course
Am Freitag, 18. Januar 2008 schrieb Magnus Hagander:
Not that much more than moving the socket file to a secure directory. Both
rely on configuring the client properly. It's arguably a lot easier to
configure the client to connect to the correct socket, than to make sure
the client has a root
On Fri, Jan 18, 2008 at 11:24:09AM +0100, Peter Eisentraut wrote:
Am Donnerstag, 17. Januar 2008 schrieb Andrew Dunstan:
I agree. I remain of the opinion that this is not a problem than can be
solved purely within the bounds of postgres.
Well, the SSL patch I showed certainly solves the
Am Donnerstag, 17. Januar 2008 schrieb Bruce Momjian:
It creates a lock file that is the same name as the socket file that a
default-configured client would use, so it prevents a spoofed socket
from being created.
A counter-spoofing solution must be implemented in the client. No moving
Am Freitag, 18. Januar 2008 schrieb Alvaro Herrera:
I propose to create a dangling symlink on system startup in
/tmp/.s.PGSQL.port to the real socket, which is not on a
world-writable directory. This avoids the spoofer, because he cannot
create the socket -- the symlink is occupying its
On Fri, Jan 18, 2008 at 12:35:40PM +0100, Peter Eisentraut wrote:
Am Freitag, 18. Januar 2008 schrieb Magnus Hagander:
Not that much more than moving the socket file to a secure directory. Both
rely on configuring the client properly. It's arguably a lot easier to
configure the client to
Bruce Momjian wrote:
I have written the following documentation addition suggesting the use
of external_pid_file.
How does that prevent spoofing?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 1: if
Peter Eisentraut wrote:
Bruce Momjian wrote:
I have written the following documentation addition suggesting the use
of external_pid_file.
How does that prevent spoofing?
It creates a lock file that is the same name as the socket file that a
default-configured client would use, so it
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
How does that prevent spoofing?
It creates a lock file that is the same name as the socket file that a
default-configured client would use, so it prevents a spoofed socket
from being created.
Only if the attacker didn't get
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
How does that prevent spoofing?
It creates a lock file that is the same name as the socket file that a
default-configured client would use, so it prevents a spoofed socket
from being created.
Andrew Dunstan wrote:
I agree. I remain of the opinion that this is not a problem than can be
solved purely within the bounds of postgres.
I agree. Please comment on my proposed solution.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication,
Alvaro Herrera wrote:
Andrew Dunstan wrote:
I agree. I remain of the opinion that this is not a problem than can be
solved purely within the bounds of postgres.
I agree. Please comment on my proposed solution.
I'm not sure tmp cleaners will work that well against a
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Andrew Dunstan wrote:
I agree. I remain of the opinion that this is not a problem than can be
solved purely within the bounds of postgres.
I agree. Please comment on my proposed solution.
I'm not sure tmp cleaners will work that well
Alvaro Herrera [EMAIL PROTECTED] writes:
I propose to create a dangling symlink on system startup in
/tmp/.s.PGSQL.port to the real socket, which is not on a
world-writable directory. This avoids the spoofer, because he cannot
create the socket -- the symlink is occupying its place.
The
Bruce Momjian [EMAIL PROTECTED] writes:
I am confused because you say dangling then you say to the real
socket. You are saying it isn't dangling when the server is running?
Exactly. When the server is running it provides a perfectly good path
to the postmaster. The point (and the main
Bruce Momjian wrote:
Alvaro Herrera wrote:
I'm not sure tmp cleaners will work that well against a determined
spoofer.
I don't understand. The tmp cleaner is something we have to _avoid_.
Let me repeat my proposal.
I propose to create a dangling symlink on system startup in
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am confused because you say dangling then you say to the real
socket. You are saying it isn't dangling when the server is running?
Exactly. When the server is running it provides a perfectly good path
to the postmaster. The
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Andrew Dunstan wrote:
I agree. I remain of the opinion that this is not a problem than can be
solved purely within the bounds of postgres.
I agree. Please comment on my proposed solution.
Bruce Momjian wrote:
Tom Lane wrote:
Conclusions:
* SSL, even without real authentication, is *way* too expensive to
enable by default.
* The extra cost of going across a local TCP connection is measurable,
but it's insignificant compared to the cost of turning on SSL. (This
is
21 matches
Mail list logo
