| From: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
|---|---|
| To: | Curt Sampson <cjs(at)cynic(dot)net> |
| Cc: | Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Sullivan <andrew(at)libertyrms(dot)info>, PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: WAL file location |
| Date: | 2002-07-31 00:00:07 |
| Message-ID: | 3D472887.6D85C413@fourpalms.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
...
> 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.
Sure, there is screaming all over the place :)
But the zeroth-order issue is not security. It is storage management for
large databases. Any scheme we have for accomplishing that must hold up
to scrutiny, but we can not refuse to proceed just because there are
"lions tigers and bears" out there.
I know you are being thoughtful about the issues, but the most secure
database is one which is not running. The most robust database is the
one with no data. We're pushing past that into large data management
issues and have to find a way through the forest. Security will be one
aspect by which we measure the solution. Scalability and robustness are
other issues, and there are still others. We'll talk about them all
before we are done ;)
- Thomas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Curt Sampson | 2002-07-31 00:09:28 | Re: WAL file location |
| Previous Message | Curt Sampson | 2002-07-30 23:46:04 | Re: WAL file location |