Skip site navigation (1) Skip section navigation (2)

Re: WAL file location

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Curt Sampson <cjs(at)cynic(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Andrew Sullivan <andrew(at)libertyrms(dot)info>,Thomas Lockhart <lockhart(at)fourpalms(dot)org>,PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WAL file location
Date: 2002-07-31 03:18:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tuesday 30 July 2002 07:46 pm, Curt Sampson wrote:
> On Tue, 30 Jul 2002, Lamar Owen wrote:
> > I said it. In any case, using strings that are in the environment
> > requires an untrusted PL, or a C function.

> Ah. See, we already have a failure in a security analysis here. This
> command:


> uses a string that's in the environment.

And requires you to be a database superuser anyway.  You got something better? 
:-)  If you're the database superuser, you can do anything you want inside 
the database.  Your analysis here is faulty.

> So what you're saying is that we should make the opportunity for people
> to configure the system in an insecure manner?

No, what I'm saying is that there is no such thing as absolute security -- and 
time is better spent where there is a measureable result.  If a security hole 
requires root to exploit, then it's not a hole.  Show me a case where an 
envvar can be exploited by an unprivileged database user without accessing a 
user written C function or some other function in an untrusted PL.

> Configuration errors by administrators are probably the number one
> cause of security breaches, you know.

No.  Failure to keep up with security updates is the number one cause of 
security breaches.  I guess you could call that a configuration problem of 
sorts.  Been there; done that.  Experienced one hack in -- caught it in the 
act.  But I _have_ been there, and I have had to clean up other people's 
configuration errors.

> I've been securing systems since I started an ISP in 1995, and so I've
> seen a lot of security vulnerabilities come and go, and I've got a bit
> of a feel for what kinds of things are typically exploited. And this one
> one just screams, "potential security vulnerability!" to me.

But, just like any other vulnerability, an admin must ask the question 'is a 
successful exploit a problem?'  Again, if an exploit requires root to 
activate, then it's not a problem in reality.  If I have to be the database 
superuser to activate an ennvar exploit in postgresql, then it's not a 
vulnerability, as I have more powerful tools at my disposal as superuser.  
Things such as DROP DATABASE.

Now if a normal user can easily exploit it remotely (like the two in a row for 
OpenBSD in the past month), then it's an issue.  A big issue.

You just have to keep perspective.  And I'm not going to put myself as any 
authority on the subject, but I do have a couple of years in the trenches, 
having admined systems for over 15 years.  I've been at it long enough to 
realize that I am most certainly fallible.
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2002-07-31 03:29:12
Subject: Re: getpid() function
Previous:From: Bruce MomjianDate: 2002-07-31 03:15:33
Subject: Re: Why is MySQL more chosen over PostgreSQL?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group