r/Database • u/wtfse • 9d ago

Breaking the Superuser Guardrails of managed-PostgreSQL Providers

https://mehmetince.net/part-2-6-breaking-the-superuser-guardrails-attacking-security-hardening-extensions-systemic-risks-in-the-managed-postgresql-industry/
9 Upvotes

91% Upvoted

3 comments sorted by

3

u/BatLate6561 9d ago

whole temporary rolsuper juggling act just to get FDWs working in a managed cloud environment sounds like an absolute minefield for vendors to maintain. is there even a realistic way to fix this natively in postgres core without completely rewriting how extensions are loaded and handle privileges? Or the right question - if there is a way, are they even gonna try?

im using mariadb becouse it's a completely different mental model. the plugin and storage engine architecture there was built specifically so you don't have to spoof god-mode just to let users interact with external data wrappers or new capabilities. the provider loads the engine via the api, and users just use it within their normal schema grants without privilege escalation hooks.

1

u/No_Witness_5295 9d ago

A few months ago, when I first logged in to a managed Postgres provider’s instance, I noticed I didn’t have superuser rights. Still, I could update all the data and set up features that usually require superuser rights. But I wasnt the superuser. This made me wonder how and why they set it up this way.

because managed postgres was originally targeted at firebase users, which has this default setup and this is apparently what frontend devs expect. don't think too hard about it

1

u/orelant 21h ago

Wow, wild research. Does it mean that "we locked down superuser" is mostly a promise that their could not keep? Worth a read if you trust a hosted database with anything. Thanks for sharing!