Behörig användare och sessionsanvändare

gäller för: Databricks SQL Databricks Runtime

När Azure Databricks kör en SQL-instruktion spårar den två distinkta användare:

• Sessionsanvändare: den användare som är ansluten till Azure Databricks och utfärdade instruktionen. Sessionsanvändaren är fast under SQL-anslutningens livslängd. Den ändras inte när en -instruktion körs, även när -instruktionen når vyer, SQL UDF:er eller lagrade procedurer.
• Behörig användare: den användare vars behörigheter kontrolleras när instruktionen som körs läser eller skriver objekt. Den behöriga användaren kan ändra när körningen går över till en vytext, en SQL UDF-brödtext eller en SQL SECURITY DEFINER procedurtext.

Funktionen session_user returnerar sessionsanvändaren.

Hur den auktoriserade användaren utvecklas

Varje anrop av en vy, SQL UDF eller lagrad procedur skickar en ny post i anropsstacken. Den behöriga användaren för en instruktion bestäms av den översta stackposten som åtgärdar en ägare:

Vyer, SQL UDF:er och SQL SECURITY DEFINER procedurer anger den behöriga användaren till sin ägare för alla instruktioner i brödtexten. En SQL SECURITY INVOKER procedur ärver den auktoriserade användaren från anroparen.

När en brödtext är klar med körningen och kontrollen återgår till anroparen, dyker den behöriga användaren tillbaka till vad den än var på samtalswebbplatsen.

Sessionsanvändaren ändras däremot aldrig under en enda anslutning. I en SQL SECURITY DEFINER procedurtext session_user() returnerar fortfarande den användare som utfärdade den ursprungliga instruktionen.

Behörigheter som kontrolleras på varje lager

Azure Databricks kontrollerar behörigheter mot den behöriga användaren vid varje körningslager:

• Sessionsanvändaren måste hålla kvar EXECUTE den översta proceduren eller funktionen och SELECT i vyn på den översta nivån. Sessionsanvändaren måste också ha USE CATALOG och USE SCHEMA på de överordnade containrarna.
• I en SQL SECURITY INVOKER procedurtext använder alla instruktioner sessionsanvändarens behörigheter, inklusive kapslade EXECUTE anrop till andra rutiner.
• I en SQL SECURITY DEFINER procedurtext, en vytext eller en SQL UDF-brödtext använder alla instruktioner ägarens behörigheter. Sessionsanvändaren behöver bara behörighet att anropa den yttre rutinen, inte behörigheter för objekten som brödtextreferenserna.

Example

Det här exemplet kedjar vyer, SQL UDF:er och lagrade procedurer som ägs av olika användare. Varje lager läser från lagret nedan, så auktoriseringen passerar hela stacken. Exemplet använder tre användare (Athos, Porthos och Aramis) och spårar vad som händer när Aramis, som endast har åtkomst till procedurerna på den översta nivån, anropar kedjan.

Inställningar

Athos skapar en tabell med två kolumner och ger Porthos läsåtkomst:

-- Run as Athos.
> CREATE TABLE t(a INT, b INT);
> INSERT INTO t VALUES (1, 10), (2, 20), (3, 30);

> GRANT SELECT ON TABLE t TO `porthos@musketeers.fr`;

Porthos skapar en vy över Athos tabell och ger Athos läsåtkomst i vyn:

-- Run as Porthos.
> CREATE VIEW v_p AS
    SELECT a, b * 100 AS b100 FROM t;

> GRANT SELECT ON VIEW v_p TO `athos@musketeers.fr`;

Athos skapar en SQL UDF som läser från Porthos vy och ger Porthos EXECUTE följande:

-- Run as Athos.
> CREATE FUNCTION f_a(p INT) RETURNS INT
    RETURN (SELECT b100 FROM v_p WHERE a = p);

> GRANT EXECUTE ON FUNCTION f_a TO `porthos@musketeers.fr`;

Porthos skapar en SQL UDF som aggregerar resultat från Athos UDF och en SQL SECURITY DEFINER procedur som exponerar resultatet:

-- Run as Porthos.
> CREATE FUNCTION f_p() RETURNS INT
    RETURN f_a(1) + f_a(2) + f_a(3);

> CREATE PROCEDURE p_def()
    LANGUAGE SQL
    SQL SECURITY DEFINER
    AS BEGIN
      SELECT f_p();
    END;

Athos skapar en SQL SECURITY INVOKER procedur som anropar Porthos procedur:

-- Run as Athos.
> CREATE PROCEDURE p_inv()
    LANGUAGE SQL
    SQL SECURITY INVOKER
    AS BEGIN
      CALL p_def();
    END;

Slutligen beviljar Athos och Porthos var och en Aramis vad han behöver för att anropa kedjan. Eftersom p_inv är en SQL SECURITY INVOKER procedur körs dess brödtext som den användare som kallade den (Aramis), och därför måste Aramis självständigt ha EXECUTE på p_def:

-- Run as Athos.
> GRANT EXECUTE ON PROCEDURE p_inv TO `aramis@musketeers.fr`;

-- Run as Porthos.
> GRANT EXECUTE ON PROCEDURE p_def TO `aramis@musketeers.fr`;

Aramis har inga behörigheter för t, f_a, v_peller f_p.

Aramis anropar kedjan

Problem med Aramis:

-- Run as Aramis.
> CALL p_inv();

Anropskedjan utvecklas på följande sätt, varje pil korsar in i en ny brödtext:

Aramis's session
   │
   │ CALL
   ▼
p_inv()      (Athos, SQL SECURITY INVOKER)
   │
   │ CALL
   ▼
p_def()      (Porthos, SQL SECURITY DEFINER)
   │
   │ SELECT
   ▼
f_p()        (Porthos's SQL UDF)
   │
   │ invokes
   ▼
f_a(p)       (Athos's SQL UDF)
   │
   │ SELECT
   ▼
v_p          (Porthos's view)
   │
   │ SELECT
   ▼
t            (Athos's table)

Följande tabell går igenom instruktionerna när de körs.

När körningen varvar ned, dyker den behöriga användaren upp lager för lager tills kontrollen återgår till Aramis session i steg 1.

Relaterade

• SKAPA PROCEDUR
• CREATE FUNCTION (SQL och Python)
• CREATE VIEW
• session_user funktion
• Privilegier och skyddsbara objekt i Unity Catalog
• GRANT