GRANT OWNERSHIP¶

Syntax¶

Für Objekttypen, die keine Instanz einer Klasse sind:

GRANT OWNERSHIP
  { ON {
            <object_type> <object_name>
          | ALL <object_type_plural> IN { DATABASE <database_name> | SCHEMA <schema_name> }
       }
    | ON FUTURE <object_type_plural> IN { DATABASE <database_name> | SCHEMA <schema_name> }
  }
  TO { ROLE <role_name> | DATABASE ROLE <database_role_name> }
  [ { REVOKE | COPY } CURRENT GRANTS ]

Für eine Instanz einer Klasse:

GRANT OWNERSHIP
  ON  <class_name> <instance_name>
  TO { ROLE <role_name> | DATABASE ROLE <database_role_name> }
  [ { REVOKE | COPY } CURRENT GRANTS ]

Erforderliche Parameter¶

object_name

Gibt den Bezeichner für das Objekt an, auf das Sie die Eigentümerschaft übertragen.

object_type

Gibt den Typ des Objekts an.

Eine der folgenden Berechtigungen:

• AGGREGATION POLICY

• ALERT

• AUTHENTICATION POLICY

• COMPUTE POOL

• DATA METRIC FUNCTION

• DATABASE

• DATABASE ROLE

• DYNAMIC TABLE

• EVENT TABLE

• EXTERNAL TABLE

• EXTERNAL VOLUME

• FAILOVER GROUP

• FILE FORMAT

• FUNCTION

• GIT REPOSITORY

• HYBRID TABLE

• ICEBERG TABLE

• IMAGE REPOSITORY

• INTEGRATION

• JOIN POLICY

• MATERIALIZED VIEW

• NETWORK POLICY

• NETWORK RULE

• PACKAGES POLICY

• PIPE

• PROCEDURE

• MASKING POLICY

• PASSWORD POLICY

• PRIVACY POLICY

• PROJECTION POLICY

• REPLICATION GROUP

• RESOURCE MONITOR

• ROLE

• ROW ACCESS POLICY

• SCHEMA

• SESSION POLICY

• SECRET

• SEQUENCE

• SNAPSHOT

• STAGE

• STREAM

• TABLE

• TAG

• TASK

• USER

• VIEW

• WAREHOUSE

object_type_plural

Pluralform von Objekttyp object_type (z. B. TABLES, VIEWS).

Beachten Sie, dass die Massenerteilung von Berechtigungen und Datenmetrikfunktionen auf Pipes nicht zulässig sind.

role_name

Der Bezeichner der Rolle, an die die Eigentümerschaft an dem Objekt übertragen wird.

database_role_name

Der Bezeichner der Datenbankrolle, an die die Eigentümerschaft an dem Objekt übertragen wird. Wenn der Bezeichner nicht vollqualifiziert ist (im Format db_name.database_role_name), sucht der Befehl die Datenbankrolle in der aktuellen Datenbank der Sitzung.

Die Eigentümerschaft ist auf Objekte in der Datenbank beschränkt, die die Datenbankrolle enthält.

Optionale Parameter¶

[ REVOKE | COPY ] CURRENT GRANTS

Gibt an, ob alle vorhandenen ausgehenden Berechtigungen für das Objekt entfernt oder übertragen werden sollen, wenn die Eigentümerschaft auf eine neue Rolle übertragen wird:

Bemerkung

Ausgehende Berechtigungen beziehen sich auf alle Berechtigungen, die für das einzelne Objekt erteilt werden, dessen Eigentümerschaft sich ändert.

Bei der Übertragung der Eigentümerschaft auf eine Rolle beziehen sich die aktuellen Berechtigungen auf alle Rollen, die der aktuellen Rolle erteilt wurden (um eine Rollenhierarchie zu erstellen). Wenn die Eigentümerschaft an einer Rolle übertragen wird, während die aktuellen Berechtigungen kopiert werden, zeigt die Ausgabe des Befehls SHOW GRANTS den neuen Eigentümer als Berechtigungsgeber aller untergeordneten Rollen der aktuellen Rolle an.

REVOKE

Setzt RESTRICT-Semantik durch, die das Entfernen aller ausgehenden Berechtigungen an einem Objekt erfordert, bevor die Eigentümerschaft auf eine neue Rolle übertragen wird. Dies soll die Rolle, die neuer Eigentümer ist, davor schützen, das Objekt unwissentlich mit bereits erteilten Berechtigungen zu erben.

Nach Übertragung der Eigentümerschaft müssen die Berechtigungen für das Objekt explizit neu an die Rolle vergeben werden.

Beachten Sie, dass das Schlüsselwort REVOKE nicht funktioniert, wenn Sie einer Rolle die Eigentümerschaft an zukünftigen Objekten eines bestimmten Typs in einer Datenbank oder einem Schema zuweisen (mit GRANT OWNERSHIP ON FUTURE <Objekttyp>).

COPY

Überträgt die Eigentümerschaft an einem Objekt zusammen mit einer Kopie aller vorhandenen ausgehenden Berechtigungen für das Objekt. Nach der Übertragung wird der neue Eigentümer im System als Berechtigungsgeber der kopierten ausgehenden Berechtigungen identifiziert (d. h. in der SHOW GRANTS-Ausgabe für das Objekt wird der neue Eigentümer in der Spalte GRANTED_BY für alle Berechtigungen aufgeführt). Infolgedessen sind alle Berechtigungen, die später vor dem Eigentümerwechsel wieder vergeben werden, nicht mehr von der ursprünglichen Rolle des Berechtigungsgebers abhängig.

Der Widerruf einer Berechtigung unter Verwendung von REVOKE <Berechtigungen> mit der Option CASCADE führt nicht zum rekursiven Widerruf dieser ehemals abhängigen Berechtigungen. Die Berechtigungen müssen ausdrücklich widerrufen werden.

Dieser Parameter erfordert, dass die Rolle, die den Befehl GRANT OWNERSHIP ausführt, über die Berechtigung MANAGE GRANTS für das Konto verfügt.

Standard: Keine. Es werden keine Operationen auf bestehenden ausgehenden Berechtigungen ausgeführt.

Bemerkung

Eine GRANT OWNERSHIP-Anweisung schlägt fehl, wenn bestehende ausgehende Berechtigungen für das Objekt weder entzogen noch kopiert wurden.

Nutzungshinweise¶

• Sie können die Berechtigung OWNERSHIP nicht auf folgende Objekte übertragen:

  • APPLICATION ROLE

  • CONNECTION

    Nur die Rolle ACCOUNTADMIN kann die Berechtigung OWNERSHIP für ein Verbindungsobjekt haben.

  • Instanzen einer Klasse.

  • Machine Learning-Objekte (d. h. Modelle, Modellversionen und Modellmonitore).

  • SERVICE

  • SHARE

• Die GRANT OWNERSHIP-Anweisung wird blockiert, wenn ausgehende (d. h. abhängige) Berechtigungen auf dem Objekt existieren. Der Objekteigentümer (oder eine höhere Rolle) kann explizit alle aktuellen Berechtigungen auf die Rolle, die neuer Eigentümer ist, kopieren (mit der Option COPY CURRENT GRANTS) oder alle ausgehenden Berechtigungen an dem Objekt zurücknehmen, bevor die Eigentümerschaft übertragen wird (mit der Option REVOKE CURRENT GRANTS).

  Wenn Sie bei Rollenobjekten diese Klauseln nicht angeben, wird die GRANT OWNERSHIP-Anweisung beim Übertragen einer Rolle auf eine neue Eigentümerrolle nicht blockiert. Die neue Eigentümerrolle wird aktualisiert. Der Befehl SHOW GRANTS OF ROLE transferred_role zeigt jedoch zwei Zeilen für die übertragene Rolle an, die demselben Benutzer erteilt wurde:

  • In der Spalte granted_by steht der Wert in einer Zeile für die Zuweisung durch die ursprüngliche Eigentümerrolle.

  • In der Spalte granted_by steht der Wert in der anderen Zeile für die Zuweisung durch die neue Eigentümerrolle.

  Snowflake verhindert die Ausführung des Befehls GRANT OWNERSHIP … REVOKE CURRENT GRANTS auf einer freigegebenen Datenbank. Weitere Informationen dazu finden Sie im Beispiel zu Freigegebene Datenbank unter diesem Thema.

• Die Übertragung der Eigentümerschaft betrifft nur die zum Ausführungszeitpunkt des Befehls vorhandenen Objekte. Alle Objekte, die nach Ausführung des Befehls erstellt werden, befinden sich im Eigentum der Rolle, die bei der Erstellung des Objekts verwendet wurde.

• Die Übertragung der Eigentümerschaft an Objekte der folgenden Typen ist gesperrt, es sei denn, folgende zusätzliche Bedingungen sind erfüllt:

  Pipes:

  Die Pipe muss angehalten sein.

  Aufgaben:

  Sie müssen die geplante Aufgabe anhalten. Snowflake hält automatisch alle Aufgaben im Container an, wenn alle Aufgaben in einer bestimmten Datenbank oder einem bestimmten Schema auf eine andere Rolle übertragen werden. Aufgaben, die mit der Option COPY CURRENT GRANTS an dieselbe Rolle übertragen werden, werden ebenfalls automatisch angehalten. Weitere Informationen dazu finden Sie unter Aufgabensicherheit.

• Wenn zukünftige Zuweisungen auf demselben Objekttyp sowohl auf Datenbank- als auch auf Schemaebene definiert werden, haben die Zuweisungen auf Schemaebene Vorrang vor den Zuweisungen auf Datenbankebene, und die Zuweisungen auf Datenbankebene werden ignoriert.

• Um die Eigentümerschaft an einer materialisierten Ansicht zu übertragen, verwenden Sie GRANT OWNERSHIP ON VIEW.... Es gibt keine separate GRANT OWNERSHIP ON MATERIALIZED VIEW-Anweisung.

• Sie können die Berechtigung OWNERSHIP weder auf eine Freigabe noch auf eine Verbindung übertragen. Nur die Rolle ACCOUNTADMIN kann Eigentümer der Verbindung sein.

• Um die OWNERSHIP-Berechtigung für dynamische Tabellen erteilen zu können, muss die empfangende Rolle über die USAGE-Berechtigung für die Datenbank und das Schema, die/das die dynamische Tabelle enthält, sowie für das Warehouse verfügen, das zur Aktualisierung der Tabelle verwendet wird. Andernfalls schlagen nachfolgende geplante Aktualisierungen fehl.

• Beim Erteilen der OWNERSHIP-Berechtigung auf zukünftige dynamische Tabellen ist Folgendes zu beachten:

  • Wenn die dynamische Tabelle so eingestellt ist, dass sie beim Erstellen initialisiert wird (d. h. INITIALIZE = ON_CREATE), stellen Sie sicher, dass die neue Rolle über ausreichende Berechtigungen für referenzierte Objekte verfügt. Andernfalls schlägt die erste Aktualisierung fehl und führt zu der Fehlermeldung, dass das Objekt nicht gefunden werden kann.

  • Wenn die dynamische Tabelle so eingestellt ist, dass sie nach Zeitplan initialisiert wird (d. h. INITIALIZE = ON_SCHEDULE), stellen Sie sicher, dass die neue Rolle über ausreichende Berechtigungen für referenzierte Objekte verfügt. Andernfalls schlagen die nachfolgenden geplanten Aktualisierungen fehl.

• Wenn Sie die Eigentümerschaft einer Apache Iceberg™-Tabelle auf eine andere Rolle übertragen, überträgt Snowflake nicht die OWNERSHIP-Berechtigung auf das externe Volume (und die Katalogintegration, wenn die Tabelle extern verwaltet wird), das mit der Tabelle verknüpft ist.

  Um der Zielrolle die volle Kontrolle über die Tabelle und die zugehörigen Objekte zu geben, müssen Sie der Rolle die OWNERSHIP-Berechtigung für das externe Volume und die Katalogintegration erteilen.

• Datenbankrollen:

  Die Eigentümerschaft kann nur an Objekte übertragen werden, die sich in derselben Datenbank wie die Datenbankrolle befinden.

• Die Übertragung der Eigentümerschaft an eine externe Tabelle oder deren übergeordnete Datenbank blockiert die automatischen Aktualisierungen der Tabellenmetadaten, indem die Eigenschaft AUTO_REFRESH auf FALSE gesetzt wird. Um die Eigenschaft nach Übertragung der Eigentümerschaft zurückzusetzen, verwenden Sie den Befehl ALTER EXTERNAL TABLE.

Beispiele¶