AWS AmazonRDS documentation change
Summary
Added documentation about object ownership mismatches during upgrades and permissions guidance
Security assessment
The changes address potential permission misconfigurations (e.g., CREATE permissions via PostgreSQL endpoint not working through TDS) and provide guidance to prevent incorrect access control. While related to security best practices, there's no indication of a specific security vulnerability being fixed.
Diff
diff --git a/AmazonRDS/latest/AuroraUserGuide/babelfish-limitations.md b/AmazonRDS/latest/AuroraUserGuide/babelfish-limitations.md index 231597ba3..77788693d 100644 --- a//AmazonRDS/latest/AuroraUserGuide/babelfish-limitations.md +++ b//AmazonRDS/latest/AuroraUserGuide/babelfish-limitations.md @@ -8,0 +9,10 @@ The following limitations currently apply to Babelfish for Aurora PostgreSQL: + * When upgrading, you might notice differences in object ownership within the same schema. Pre-upgrade objects are owned by the current user while post-upgrade objects are owned by the schema owner, which might be a different user. To address this, we introduced the `sys.generate_alter_ownership_statements()` function. + +To fix object ownership mismatches, connect to your cluster using the PostgreSQL endpoint, run the sys.generate_alter_ownership_statements() function, and execute the generated SQL statements. + +Consider these important limitations related to object ownership changes: + + * Users who are granted CREATE permissions through the PostgreSQL endpoint can't create objects through the TDS endpoint. We don't recommend changing permissions on T-SQL objects through the PostgreSQL endpoint because it can lead to incorrect T-SQL behavior. + + * Object access permissions might change. For example, if a schema owned by 'sch_own' contains objects owned by 'dbo' before upgrade, users' ability to perform operations like SELECT or INSERT might differ between pre-upgrade objects (owned by 'dbo') and post-upgrade objects (owned by 'sch_own'). +