Posted by ozirus 5 hours ago
These seem more like privilege escalation, you have access through a database account and use that to gain full access to the whole server. So an issue for multi-tenant databases mostly.
CREATE ROLE initial LOGIN NOINHERIT NOCREATEDB NOCREATEROLE NOSUPERUSER;
And then you run SQL to validate any credentials and then check the database for any permissions, ending with SET LOCAL ROLE someuser;
It is uncommon but some people appreciate the simplicity of making the application layer do as little work as possible while pushing work into the database. It’s the logical conclusion after years of telling developers about the N+1 query problem.According to the article, Postgres has an internal Datum that might be a pointer or not a pointer. Okay, this is already a bit risky.
Datum comes along with a small-integer type id. That id is stored separately, presumably for efficiency? Maybe you have lots of Datums and one id and you do this for efficiency. Okay, as long as there is a clear story for why the id stays correctly bound to the datum. The “internal” thing where a bogus AST will cause type confusion makes me think the story here isn’t great.
But then I learn that the type id is something that the code looks up in a system table in the database. I’m speechless. This is the kind of thing that can’t be represented in any safe language because the indication of whether a value is a pointer isn’t even in application memory.
Eww. Maybe the AIs can exhaustively enumerate every code path that might get it wrong and rule them all out in a particular release. Maybe there’s even a Lean program that can verify it. But this is still the kind of design that is wrong by construction and is only okay if every single detail avoids the giant foot-cannon.