On Tue, Aug 14, 2018 at 5:14 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > I think you are interpreting the problem too broadly. This is basically > just a privilege escalation attack vector.
Hmm. Well, I think you're interpreting the problem too narrowly. :-) In my view, the problem isn't just that there is a risk of privilege escalation; in fact, for many users, that's not a serious problem at all because the database has only one user anyway. I think that the core problem is that you can easily write code that looks like it will work just fine and then have it not work at all. For example, somebody: - creates an SQL or PL/plgsql function - uses it to define a functional index - runs REINDEX with a different search path - gets an error because there's some unqualified or ambiguous reference inside the SQL function There might be a security risk here if the REINDEX is run by a different user with elevated privileges, because then maybe one of the references inside the SQL or PL/plgsql function could be captured by a new and malicious object injected into the alternative search path, but that's not really the point. The point is that you might reasonably want this to WORK AS INTENDED, not just fail to be insecure. If your house gets hit by lightning and, as a result, your alarm system goes offline, you do have a potential security problem, but also, every appliance in your house is probably fried, and your house may be on fire. Focusing on the security system specifically is likely the wrong approach. So here. What we want, I think, is a way to create the SQL or PL/pgsql function in such a way that it knows what search path was intended and uses that search path for the SQL that occurs within it. Then, the security problem goes away, but even better, the code works. This is also my basic complaint about the TRUST mechanism: it's not a bad idea, but it seems to me to be tackling the problem from the wrong end. If somebody tries to make it so that when I run pg_dump they hack superuser, having pg_dump error out is surely better than letting them hack superuser. However, having pg_dump error out, while surely better than a privilege compromise, is also not great, because I now don't have a backup. In a sense, I haven't eliminated the security vulnerability at all; I've just reduced the consequences from hack-superuser to deny-successful-backup. But deny-successful-backup is still a pretty bad consequence. What I really want is for pg_dump to succeed in giving me a correct backup, without compromising security. Similar with an attack on any other application. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
