On Sat, 14 May 2005 04:34 am, Andrew Dunstan wrote:
> 
> Andrew - Supernews wrote:
> 
> >>
> >>1) The "ISP" case, where you want to hide all catalog information from the 
> >>users except the database owner or superuser.
> >>    
> >>
> >
> >I don't believe this is ever feasible in practice, since client interfaces
> >at any level higher than libpq will need to access metadata corresponding
> >to the data they are retrieving.
> >
> >  
> >
> 
> In the general case you might well be right. Following a scheme like I 
> have in mind is not something that would be transparent to the 
> application - it will probably impose some serious limits on the app. 
> The little sample application I did for testing did everything by stored 
> procedure. Anyway, as I said, it's a project for the future.
> 
>From a general user point of view, I do not know the system catalogs very 
well. I am very unsure of what level of information is available to every 
user on the system.

- Which parts of other databases can be seen by users?
- What is the best method to restrict connections to db's people don't have 
permissions to.
- Is there some restrictions you can place on tables people don't have access 
too.  Otherwise they can see all the columns and table info.

These are just some of the questions I have, I'm not sure where to get 
answers, searching the archives may help, but it's definitely not a final 
answer.  Especially since this stuff would be a moving target with each 
version change of PostgreSQL.

Tom mentioned that he had not had these security concerns raised before.  From 
my point of view I just have no idea about the level of information offered 
to any given user and am scared to run PostgreSQL in an ISP shared 
environment because of it.  I am sure I can secure people from connecting to 
a db by refusing them access in pg_hba.conf.  But I'm unsure of exactly what 
that buys me, and what is doesn't.

A hardening script would be helpful, but some clear information on what is 
also available to the average user would be good too.  I know I should 
probably step up to do this and don't have time at the moment.  I'm sure if I 
did, I would also miss a great number of things.

Regards

Russell Smith

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq

Reply via email to