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

Re: WAL file location

From: Curt Sampson <cjs(at)cynic(dot)net>
To: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
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 04:36:44
Message-ID: Pine.NEB.4.44.0207311331220.493-100000@angelic.cynic.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, 30 Jul 2002, Lamar Owen wrote:

> On Tuesday 30 July 2002 07:46 pm, Curt Sampson wrote:
>
> > Ah. See, we already have a failure in a security analysis here. This
> > command:
>
> >     CREATE DATABASE foo WITH LOCATION = 'BAR'
>
> > uses a string that's in the environment.
>
> And requires you to be a database superuser anyway.

Yup. So once again, we're getting in to the loop "well, if you do
this, this other layer of security protects from some other thing
and blah blah blah."

Given the choice between doing something simple that eliminates one
possible avenue of security holes, or doing an extensive, error-prone
analysis, to try to prove that that avenue doesn't have any holes and is
not likely to have any in the future, which is going to be more secure?

> 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.

Well, if this is your approach to security, we're just going to
have to stop arguing here. The correct approach to security is not,
"leave this line of attack open, if we can't show how it could
fail" but "close off that line of attack even if we can't show how
it would fail." If you don't agree with that, you're in disagreement
with me and every Internet security expert out there.

> No.  Failure to keep up with security updates is the number one cause of
> security breaches.

Bzzt!

cjs
-- 
Curt Sampson  <cjs(at)cynic(dot)net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC


In response to

pgsql-hackers by date

Next:From: Curt SampsonDate: 2002-07-31 04:40:21
Subject: Re: Rules and Views
Previous:From: Bruce MomjianDate: 2002-07-31 04:35:28
Subject: Re: Open 7.3 items

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