Re:SAML Is Insecure by Design
by KptMarchewa on Friday August 06, 2021 @04:59AM
(#28084784)
"Just" don't use the same database that the application is using for it's internal data.
You can scope the DDL permissions to a single schema while still using the same database (and benefit from all the transactional guarantees a single database offers).
Re:SAML Is Insecure by Design
by KptMarchewa on Friday August 06, 2021 @07:44AM
(#28085796)
Yes, if database supports it (I guess every major ones now do) then it's great. Postgres's transactional DDL seems like great fit.
Re:SAML Is Insecure by Design
by ThePadawan on Friday August 06, 2021 @07:12AM
(#28085566)
I'm sorry, I don't follow.
I was talking about an application and its accompanying database, which would still be paid for and administered by the customer, not a database outside the application which it would be accessing.
That still raised many eyebrows.
I think the GP was assuming the reason sysadmins worry about running DDL is the danger of overwriting/modifying tables the application depends on.
If this is the main concern, you could have two databases (or schemas, if your database supports it).
One for application configuration/storage that the application never runs DDL on and another for user data, where the tables can be created/modified dynamically.
That separation means that, at worst, user data is screwed up if there's a bug in the DDL generation, but the application should still be able to run.
At least, that was my read.
Turns out sysadmins get REALLY nervous when you tell them your application needs permission to use DDL at runtime. It required a lot more filling out forms.