Re: Insufficient attention to security in contrib (mostly)

We seem to be down to arguing about what permissions are needed to
execute the tablespace-size functions. I wrote:

> * tablespace-size function requires being owner of current DB.
> There is nothing particularly principled about the last choice, but
> it's not superuser and not wide open either.

> Another option for tablespace-size is that you must have CREATE on the
> target tablespace. This is also not real principled, since CREATE is
> more of a "write" privilege than a "read" one, but it'd at least give
> DBAs some tool to work with.

> Also, I don't see anything very wrong with defining USAGE on a
> tablespace to mean that you can use the tablespace-size function on it.
> AFAIR the overhead for allowing an existing privilege keyword to apply
> to another type of object is just about nil --- a couple macro changes.

Bruce and I were just chatting about this, and we came up with a couple
of fairly good arguments against the first option (that DB owners can
use it):

* DB owners are supposed to have special permissions within their own
DB, but not necessarily system-wide; so being a DB owner shouldn't in
itself grant privileges to check tablespace sizes for tablespaces you
otherwise have no access to.

* Dave was concerned about being able to use tools that connect to
postgres or template1 by default. Well, those databases are almost
certainly going to be owned by postgres, so for such a tool to be able
to use a DB-owner-only function, it's gonna have to be superuser or
darn near.

So I think I don't like that idea at all. And the third one does seem
like overkill. Bruce likes the CREATE-privilege option on the grounds
that if you have the right to make tables in a tablespace, you should
have the right to find out how big it is. From a security point of
view, you can find it out indirectly if you have some idea how big a
disk partition it's mounted on: fill up a temp table until you run out
of disk space, and subtract. So trying to deny the knowledge seems a
bit pointless anyway.

Therefore, I propose the same choices as before for table-size (no
restriction) and database-size (must have CONNECT priv), and this
for tablespace-size: you must have the ability to create tables in
the target tablespace. This could be either an explicit CREATE
grant, or implicit because you are in a DB that has it as the default
tablespace.

Comments?

regards, tom lane