document the dangers of granting TRIGGER or REFERENCES

For many years now, the PostgreSQL security team has been receiving
reports that the TRIGGER and REFERENCES permissions are dangerous to
grant. This is not news, at least to me, and I actually feel like I
remember Tom making some comment about this on this list a long time
ago, but the searches I have tried so far have failed to locate that
email, so either I hallucinated it (heh, heh) or my search-fu is not
up to the task.

But for reasons which many of you may be able to guess, the rate of
such reports has increased lately, and I rather suspect it will
continue to increase. While that's frustrating, it is also true that
this is something that really should be called out in the
documentation, so here's a patch to do that. I modeled this on the
existing language we use for granting pg_execute_server_program. If
you don't like that language, feel free to suggest alternatives.

Before somebody asks, the security team does not regard this as a
security vulnerability per se, but rather as a natural consequence of
letting somebody do things to your table that have the effect of
causing code chosen by them to be executed. At least for TRIGGER, I
think this is pretty intuitive. If you cannot foresee that letting
someone create triggers on your table might lead to a security
exposure, you haven't thought very hard. The issue with REFERENCES is
admittedly more subtle. At least to me, it's abundantly clear that
letting your arch-nemesis create foreign keys pointing to your table
is a bad idea, because they'll probably use that access to make your
life miserable. I find it somewhat less clear, but it is nonetheless
true, that it lets them run code of their choosing as you -- and
AFAICS there's nothing we can really do about that without removing
SQL functionality upon which lots of people depend.

IMHO, apart from patching the documentation, the other thing we might
want to consider doing is removing one or both of these privileges
entirely, and making them part of table ownership. I think there's
basically no scenario where granting an untrusted user even limited
permission to perform DDL on your objects is a sensible thing to do.
In this case, and in a whole lot of similar cases, such changes will
imply some ability on the part of the grantee to cause functions of
their choosing to be invoked by you or by other users who access your
object, at which point granting them that specific privilege rather
than full rights to your account is just security theatre.

--
Robert Haas
EDB: http://www.enterprisedb.com