Skip to content

Commit f4fdf07

Browse files
authored
Update pg_write_all_data behvaior to recent product changes
Updated behavior for changes in M58. Also updated author information and publication date
1 parent 2ce93b4 commit f4fdf07

1 file changed

Lines changed: 2 additions & 5 deletions

File tree

articles/postgresql/security/security-access-control.md

Lines changed: 2 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -2,9 +2,9 @@
22
title: Access Management
33
description: Learn how to manage access permissions for Azure Database for PostgreSQL using roles.
44
author: techlake
5-
ms.author: hganten
5+
ms.author: talawren
66
ms.reviewer: maghan
7-
ms.date: 09/19/2025
7+
ms.date: 05/21/2026
88
ms.service: azure-database-postgresql
99
ms.subservice: security
1010
ms.topic: concept-article
@@ -141,9 +141,6 @@ This is a built-in safeguard to prevent changes to critical administrative roles
141141

142142
In PostgreSQL 16, a strict role hierarchy structure is implemented for users with the [CREATEROLE](https://www.postgresql.org/docs/16/sql-createrole.html) privilege, specifically related to grant roles. To improve administrative flexibility and address a limitation introduced in PostgreSQL 16, Azure Database for PostgreSQL enhances the capabilities of the *azure_pg_admin* role across all PostgreSQL versions. With this update, members of the *azure_pg_admin* role can manage roles and access objects owned by any nonrestricted role, even if those roles are also members of *azure_pg_admin*. This enhancement ensures that administrative users maintain consistent and comprehensive control over role and permission management, providing a seamless and reliable experience without requiring superuser access.
143143

144-
> [!IMPORTANT]
145-
> Azure Database for PostgreSQL doesn't allow users to be granted *pg_write_all_data* attribute, which allows user to write all data (tables, views, sequences), as if having `INSERT`, `UPDATE`, and `DELETE` rights on those objects, and USAGE rights on all schemas, even without having it explicitly granted. As a workaround recommended granting similar permissions on a more finite level per database and object.
146-
147144
## Row-level security
148145

149146
[Row-level security (RLS)](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) is an Azure Database for PostgreSQL security feature that enables database administrators to define policies that control how specific rows of data display and operate for one or more roles. Row-level security adds an extra filter to an Azure Database for PostgreSQL database table. When a user tries to perform an action on a table, this filter is applied before the query criteria or other filtering, and the data narrows or rejects according to your security policy. You can create row-level security policies for specific commands like `SELECT`, `INSERT`, `UPDATE`, and `DELETE`, or specify it for all commands. Use cases for row-level security include PCI-compliant implementations, classified environments, and shared hosting or multitenant applications.

0 commit comments

Comments
 (0)