Re: Insufficient attention to security in contrib (mostly) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Insufficient attention to security in contrib (mostly)
Date
Msg-id 9081.1188251185@sss.pgh.pa.us
Whole thread Raw
In response to Re: Insufficient attention to security in contrib (mostly)  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Insufficient attention to security in contrib (mostly)  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
> Tom,
>> That's OK for individual tables, but we have no equivalent concept for
>> whole databases or tablespaces.  What do you propose for them?

> CONNECT, of course.  There are no permissions for tablespaces except 
> CREATE, so presumably if the user can connect to the db, they ought to be 
> able to see the size of the tablespaces. 

Uh, if you agree that a user shouldn't be able to find out the size of a
table he can't read, why is it OK to find out the size of the database
or tablespace containing it?  In typical cases where there's just one or
a few large tables, the latter number would go far towards giving you
the former.  For instance, if you are allowed to access all but one
table in a DB, subtraction will give you its size exactly.  In the same
way at the next level up, access to tablespace stats would tell a user a
lot about the size of databases he isn't supposed to have access to.

[ thinks for awhile... ]

It does strike me that there's a good reason for not restricting the
table-size functions: anyone who can look at pg_class.relpages can get
a maybe-not-up-to-date version of the same number.  There are probably
some corner cases where exact knowledge is more interesting than
approximate knowledge, but it's hard to justify a blanket prohibition.
So maybe we should forget the restriction on the table size functions.

However, the pg_class argument doesn't extend to letting someone find
out the size of a database he's not supposed to be able to get into.

One possibility would be to make the tablespace size function silently
ignore any per-database subdirectories for which the current user
doesn't have CONNECT privilege.  I'm not exactly thrilled with that,
though --- functions that silently lie to you are a great foot-gun.

Another idea is to not hardwire any restriction into the C code, but
instead have initdb revoke the default public execute access on the
tablespace size function.  It would still work for superusers, and
a particular DBA could choose to grant execute to trustworthy people.
The problem is that you'd have to repeat the grant over and over
(in particular, pg_dump wouldn't save its effects).
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: MSVC build system
Next
From: Magnus Hagander
Date:
Subject: Re: MSVC build system