From: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
---|---|
To: | jeff sacksteder <jsacksteder(at)gmail(dot)com> |
Cc: | Richard Huxton <dev(at)archonet(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: security documentation |
Date: | 2005-09-30 15:51:18 |
Message-ID: | 1128095478.29347.82.camel@state.g2switchworks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 2005-09-30 at 09:14, jeff sacksteder wrote:
> Are there any data access issues (as opposed to data visibility
> issues)
> you are having?
>
>
> No, It's just that in a hosting situation where each customer has a
> database of their own, they need to be boxed in somehow. In the event
> of an application bug allowing raw sql to be executed, it's not
> appropriate for them to be able to learn what other databases and
> users exist.
Well, the fact that they're still on the same database cluster is the
real issue then. If you need true isolation, then each one needs their
own (possibly virtual) server.
No matter how much you might be able to hide the other databases,
they're still there, and issuing an unconstrained join can still pretty
much kill everyone else's performance.
From | Date | Subject | |
---|---|---|---|
Next Message | Gandalf Me | 2005-09-30 15:52:28 | Exporting just schema/metadata (w/o data) in Postgres |
Previous Message | Devrim GUNDUZ | 2005-09-30 15:48:44 | Re: Redhat 9 RPM dependency problem |