通过

迁移服务的迁移场景中的权限

  • 项目

适用于： Azure Database for PostgreSQL 灵活服务器

对于以 Azure Database for PostgreSQL 单一服务器作为源进行数据迁移，Azure Database for PostgreSQL 中的迁移服务提供以下内置功能：

  • 将源服务器上的用户角色迁移到目标服务器。
  • 将源服务器上的所有数据库对象所有权迁移到目标服务器。
  • 将源服务器上的数据库对象权限（如 GRANT 和 REVOKE）迁移到目标服务器。

重要

仅当源是 Azure Database for PostgreSQL 单一服务器实例时，才能迁移用户、角色、所有权和权限。 目前，此功能不适用于 PostgreSQL 版本 16 服务器。

单一服务器与灵活服务器上的权限比较

本部分介绍了在 Azure Database for PostgreSQL 单一服务器和 Azure Database for PostgreSQL 灵活服务器环境中授予给 azure_pg_admin 角色的权限之间的差异。

pg_catalog 架构权限

与用户创建的用于将数据库对象组织成逻辑组的架构不同，pg_catalog 是一个系统架构。 它包含关键的系统级信息，例如有关表、列和其他内部簿记数据的详细信息。 pg_catalog 架构是 PostgreSQL 存储重要元数据的地方。 权限在单一服务器环境和灵活服务器环境中有所不同：

  • 在单一服务器环境中，属于 azure_pg_admin 角色的用户会被授予对所有 pg_catalog 表和视图的特定权限。
  • 在灵活服务器环境中，某些表和视图的权限会受到限制，只有超级用户才能查询。

对 pg_catalog 架构中的系统表和视图授予不受限制的访问权限可能会导致未经授权的修改、意外删除，甚至安全漏洞。 受限访问可降低意外更改或数据泄露风险。

我们移除了非超级用户对以下 pg_catalog 表的所有权限：

  • pg_authid

  • pg_largeobject

  • pg_statistic

  • pg_subscription

  • pg_user_mapping

我们移除了非超级用户对以下 pg_catalog 视图的所有权限：

  • pg_config

  • pg_file_settings

  • pg_hba_file_rules

  • pg_replication_origin_status

  • pg_shadow

pg_pltemplate 弃用

另一个重要的注意事项是 pg_pltemplate 系统表的弃用。 从版本 13 开始，PostgreSQL 社区会弃用 pg_catalog 架构中的 pg_pltemplate 系统表。 如果迁移到 Azure Database for PostgreSQL 灵活服务器版本 13 或更高版本，并且已向用户授予对单一服务器上 pg_pltemplate 表的权限，则必须在启动迁移之前撤销这些权限。

效果

下面列出了 pg_pltemplate 弃用的重要影响：

  • 如果应用程序设计为直接查询相关表和视图，则迁移到灵活服务器时会遇到问题。 强烈建议你重构应用程序，以避免对这些系统表进行直接查询。

  • 如果已向任何用户或角色授予或撤销了对相关 pg_catalog 表和视图的权限，则迁移过程中会出现错误。 可按以下模式识别此错误：

    pg_restore error: could not execute query <GRANT/REVOKE> <PERMISSIONS> on <relevant TABLE/VIEW> to <user>.

解决方法

若要解决 pg_catalog 错误，请删除已向用户或角色授予的与相关 pg_catalog 表和视图相关的权限。

步骤 1：识别权限

以管理员用户身份登录，在单一服务器上执行以下查询。

在代码中：

  • 权限称为“特权”。
  • relation_name 值是表名或视图名。
SELECT
  array_to_string(array_agg(acl.privilege_type), ', ') AS privileges,
  t.relname AS relation_name, 
  r.rolname AS grantee
FROM
  pg_catalog.pg_class AS t
  CROSS JOIN LATERAL aclexplode(t.relacl) AS acl
  JOIN pg_roles r ON r.oid = acl.grantee
WHERE
  acl.grantee <> 'azure_superuser'::regrole
  AND t.relname IN (
    'pg_authid', 'pg_largeobject', 'pg_subscription', 'pg_user_mapping', 'pg_statistic',
    'pg_config', 'pg_file_settings', 'pg_hba_file_rules', 'pg_replication_origin_status', 'pg_shadow', 'pg_pltemplate'
  )
GROUP BY
  r.rolname, t.relname;
步骤 2：查看输出

查询的输出显示向角色授予的对相关表和视图的权限列表。

例如：

权限 表或视图（关系名称） 被授权者
SELECT pg_authid adminuser1
选择，更新 pg_shadow adminuser2
步骤 3：撤销权限

若要撤消权限，请针对被授权者对表或视图的每个权限运行 REVOKE 语句。

例如：

REVOKE SELECT ON pg_authid FROM adminuser1;
REVOKE SELECT ON pg_shadow FROM adminuser2;
REVOKE UPDATE ON pg_shadow FROM adminuser2;
步骤 4：最终验证

再次运行步骤 1 中的查询，以确保生成的输出集为空。

注意

为了避免在迁移过程中出现任何与权限相关的问题，请确保为迁移中包含的所有数据库完成上述步骤。

完成这些步骤后，可以使用迁移服务启动从单一服务器到灵活服务器的迁移。

相关内容