Insufficient attention to security in contrib (mostly)

I noticed a number of functions, most but not all in contrib, which
allow an unprivileged user to obtain varying amounts of information
about a relation he has no permissions to access:

dblink_get_pkey() will tell you what its primary key is. This is not
a big deal seeing that you can get the info by looking into the system
catalogs, but someone who was trying to lock down the system catalogs
wouldn't be happy. I think this should require SELECT privilege on
the table.

btreefuncs.c is a security hole a mile wide: it will happily dump the
entire data content of an index for you. It's a good thing this hasn't
shipped in any release yet. While we could possibly make it look up
the index's parent table and check if you have SELECT privilege on
that, it'd be easier just to make the functions demand superuser
privilege, which is what the rest of the functions in this contrib
module require. Comments?

pgrowlocks tells you about row lock states, which maybe is not that
interesting for security, but still it's information that one wouldn't
expect to be exposed to someone who isn't allowed to read the table.
I suppose knowing the number of live tuples might in itself be
sensitive information.

If you do think that's sensitive information, you probably won't be
happy that pgstattuple and pgstatindex likewise have no permission
checks. The same goes for the various size-calculation functions in
the backend's adt/dbsize.c file. The latter should probably require
superuser, particularly for the functions that are willing to tell
you about whole databases you can't get into.

currtid_byrelname() and currtid_byreloid() have no permission checks
either. I'm not sure that TID relationships can be used for anything
interesting, but ...

Lastly, int4notin() and oidnotin() have no permission checking, which
means you can find out whether specific values are or are not present
in an int4 or oid column you shouldn't read. This code is so old,
crufty, and undocumented that I'm strongly inclined to remove it
instead of fix it --- it really has no excuse to live when we support
IN (sub-SELECT) constructs.

Comments?

regards, tom lane