My understanding of the sentence is that if pg_dump is executed with privileged permissions, the arbitrary SQL function run at the same time will also run with those permissions. So if you have a nightly cron which does pg_dump with the superuser permission, then it’s possible for someone to run a SQL statement to create a stored procedure using that superuser permission.
I’d imagine that would depend on the deployment and environment. Chaining exploits is not unheard of. Maybe a lazy dev figured it’s easier to stop a devastating SQL injection by just restricting the permissions of the client connecting. Or maybe you have an intern with malicious intentions to destroy your company, but you only gave them read access to the database so you assume they can’t drop tables.
Basically taking the Swiss Cheese Model approach, there may be security gaps in the front line but as long as subsequent lines of defense don’t also have big holes, the risk is minimized.
My understanding of the sentence is that if
pg_dumpis executed with privileged permissions, the arbitrary SQL function run at the same time will also run with those permissions. So if you have a nightly cron which doespg_dumpwith the superuser permission, then it’s possible for someone to run a SQL statement to create a stored procedure using that superuser permission.So how does that SQL statement make it into the database in the first place?
I’d imagine that would depend on the deployment and environment. Chaining exploits is not unheard of. Maybe a lazy dev figured it’s easier to stop a devastating SQL injection by just restricting the permissions of the client connecting. Or maybe you have an intern with malicious intentions to destroy your company, but you only gave them read access to the database so you assume they can’t drop tables.
Basically taking the Swiss Cheese Model approach, there may be security gaps in the front line but as long as subsequent lines of defense don’t also have big holes, the risk is minimized.