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 postmast
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
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 ro
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
Am Freitag, 18. Januar 2008 schrieb Alvaro Herrera:
> I propose to create a dangling symlink on system startup in
> /tmp/.s.PGSQL. 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.
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 cours
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
aro
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
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.
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 postmast
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 syst
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
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
> /tmp/.s.PGSQL. to the real
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I propose to create a dangling symlink on system startup in
> /tmp/.s.PGSQL. 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 o
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 wil
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 determined
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
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
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
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 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 p
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 SS
22 matches
Mail list logo
