|
Home > Archive > PostgreSQL Discussion > September 2005 > security documentation
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
security documentation
|
|
| jeff sacksteder 2005-09-29, 8:23 pm |
| The security documentation available in the official documentation is rather
sparse. Is there a more detailed document I should be aware of?
As an example, I'd like to prevent a a user from being able to get a list of
existing databases. Presumably, I can limit access to various system
catalogs to prevent this sort of thing, but if existing documentation exists
it might prevent me from shooting myself in the foot too badly.
| |
| Peter Eisentraut 2005-09-30, 3:23 am |
| Am Donnerstag, 29. September 2005 21:46 schrieb jeff sacksteder:
> As an example, I'd like to prevent a a user from being able to get a list
> of existing databases.
You can't do that.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
| |
| Richard Huxton 2005-09-30, 3:23 am |
| jeff sacksteder wrote:
> The security documentation available in the official documentation is rather
> sparse. Is there a more detailed document I should be aware of?
No.
> As an example, I'd like to prevent a a user from being able to get a list of
> existing databases. Presumably, I can limit access to various system
> catalogs to prevent this sort of thing, but if existing documentation exists
> it might prevent me from shooting myself in the foot too badly.
Limiting access to the system catalogues is not simple. I do recall
someone who was trying - might be worth checking the mailing list archives.
Are there any data access issues (as opposed to data visibility issues)
you are having?
--
Richard Huxton
Archonet Ltd
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
| |
| jeff sacksteder 2005-09-30, 11:23 am |
| 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.
| |
| Scott Marlowe 2005-09-30, 11:23 am |
| 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.
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
|
|
|
|
|