Thread: security documentation
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.
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.
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/
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
Are there any data access issues (as opposed to data visibility issues)
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.
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.
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.