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
v1-0001-doc-Granting-TRIGGER-or-REFERENCES-on-table-is-da.patch
Description: Binary data
