Re: Insufficient attention to security in contrib (mostly)

Josh Berkus <josh(at)agliodbs(dot)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