it-swarm.com.de

GRANT SELECT ON SEQUENCE ist erfolgreich, aber ohne Wirkung?

Ich versuche, ausgewählten Zugriff auf Sequenzen von einem Benutzer/einer Rolle zu einem anderen zu gewähren. Es gibt keine Fehler, wenn ich den Befehl ausführe, aber sobald er ausgeführt wird, kann die zweite Rolle die Sequenzen nicht anzeigen. Ich habe genau den gleichen Befehl auf mehreren anderen Diensten/Datenbankinstanzen ausgeführt, die erfolgreich waren. Dies ist nur eine Fehlfunktion.

Ich habe beide ausgeführt:

GRANT SELECT ON ALL SEQUENCES IN SCHEMA schema_name TO new_role;

Gemäß der Empfehlung hier:

Und wie oben erwähnt, war dies auf anderen Datenbankschemata auf verschiedenen Computern erfolgreich. Ich habe es auch einzeln versucht:

GRANT SELECT ON SEQUENCE some_id_sequence TO new_role;

und

GRANT SELECT ON SEQUENCE public.some_id_sequence TO new_role;

Dies hat auch keine Auswirkung. Wenn Sie von new_role Aha:

select * from information_schema.role_usage_grants ; 
...
(0 rows)

Ähnliche Ergebnisse (oder deren Fehlen) beim Ausführen von \ds.

Ich kann der vorherigen Rolle entnehmen, dass die Sequenz "gewährbar" sein sollte (was auch immer das bedeutet, ich kann keine Dokumentation dazu finden)

[email protected] ~ => select * from information_schema.role_usage_grants limit 1;
┌──────────┬──────────┬────────────────┬───────────────┬──────────────┬─────────────┬────────────────┬──────────────┐
│ grantor  │ grantee  │ object_catalog │ object_schema │  object_name │ object_type │ privilege_type │ is_grantable │
├──────────┼──────────┼────────────────┼───────────────┼──────────────┼─────────────┼────────────────┼──────────────┤
│ old_role │ old_role │ old_role       │ public        │ some_id_seq  │ SEQUENCE    │ USAGE          │ YES          │
└──────────┴──────────┴────────────────┴───────────────┴──────────────┴─────────────┴────────────────┴──────────────┘
(1 row) 

Ich weiß also nicht wirklich, wo ich an diesem Punkt suchen soll. Die alte Rolle scheint die Möglichkeit zu haben, anderen Rollen eine Auswahl zu gewähren, und es tritt kein Fehler auf, wenn versucht wird, den Befehl auszuführen. Die neue Rolle hat jedoch immer noch keinen Zugriff.

Die ergebnisse von \dn+

\dn+
                  List of schemas
┌───────────┬──────────┬────────────────────────┬─────────────┐
│  Name     │ Owner    │ Access privileges      │ Description │
├───────────┼──────────┼────────────────────────┼─────────────┤
│ new_role  │ old_role │ old_role=UC/old_role  ↵│             │
│           │          │ new_role=U/old_role    │             │
│ public    │ old_role │                        │             │
└───────────┴──────────┴────────────────────────┴─────────────┘
(2 rows)

\du+ new_role
                   List of roles
┌───────────┬────────────┬───────────┬─────────────┐
│ Role name │ Attributes │ Member of │ Description │
├───────────┼────────────┼───────────┼─────────────┤
│ new_role  │            │ {}        │             │
└───────────┴────────────┴───────────┴─────────────┘

Die Ergebnisse von \dp

\dp some_id_sequence
                                     Access privileges
┌────────┬──────────────────┬──────────┬───────────────────────┬───────────────────┬──────────┐
│ Schema │       Name       │   Type   │ Access privileges     │ Column privileges │ Policies │
├────────┼──────────────────┼──────────┼───────────────────────┼───────────────────┼──────────┤
│ public │ some_id_sequence │ sequence │ old_role=rwU/old_role │                   │          │
│        │                  │          │ new_role=r/old_role   │                   │          │
└────────┴──────────────────┴──────────┴───────────────────────┴───────────────────┴──────────┘

Frage: Wie stelle ich fest, was die Anwendung der Sequenzzuschüsse verhindert?

3
Mitch Kent

GRANT'ing SELECT (oder USAGE) für die Sequenz ist nicht ausreichend, wenn es in einem Schema enthalten ist, für das der Benutzer keine Berechtigung hat. Ich glaube, das ist der Fall, weil Ihr Schema mit dem Namen public nicht öffentlich ist. Wenn es so wäre, hätte es Berechtigungen, die so aussehen würden:

test=> \dn+
                          List of schemas
  Name  |  Owner   |  Access privileges   |      Description       
--------+----------+----------------------+------------------------
 public | postgres | postgres=UC/postgres+| standard public schema
        |          | =UC/postgres         | 

im Gegensatz zu den in der Frage gezeigten fehlenden Zugriffsrechten. Dies steht auch im Einklang mit der Tatsache, dass dieselben Befehle in anderen Instanzen funktionieren: Vermutlich ist das Schema public dieser anderen Datenbanken das Original, keine abgelegte/neu erstellte Version oder mit entfernten Berechtigungen.

Als mögliche Lösungen sollten Sie als Eigentümer des Schemas Folgendes in Betracht ziehen:

 GRANT ALL ON SCHEMA public TO public;

oder je begrenzter

 GRANT ALL ON SCHEMA public TO new_role;

oder die noch begrenzter

 GRANT USAGE ON SCHEMA public TO new_role;
2
Daniel Vérité

Das Handbuch :

Die Ansicht role_usage_grants Identifiziert USAGE Berechtigungen, die für verschiedene Arten von Objekten gewährt werden, bei denen der Grantor oder Grantee eine derzeit aktivierte Rolle ist.

Nach GRANT SELECT ... Wird dort nichts mehr angezeigt. Versuchen Sie stattdessen:

GRANT USAGE ON SEQUENCE public.some_id_sequence TO new_role;

.. wenn es das ist, was du willst. Das SELECT Privileg hat eine begrenzte Verwendung für ein SEQUENCE, es erlaubt currval() und lastval() .
Normalerweise möchten Sie das Privileg USAGE, das auch das entscheidende nextval() zulässt. zusätzlich zu den oben genannten. Zum Beispiel, um mit einer serial -Spalte zu arbeiten. Sehen:

Warum sehen Sie diese verwirrende Zeile in Ihrem Test, nachdem Sie SELECT gewährt haben?

[email protected] ~ => select * from information_schema.role_usage_grants limit 1;
┌──────────┬──────────┬────────────────┬───────────────┬──────────────┬─────────────┬────────────────┬──────────────┐
│ grantor  │ grantee  │ object_catalog │ object_schema │  object_name │ object_type │ privilege_type │ is_grantable │
├──────────┼──────────┼────────────────┼───────────────┼──────────────┼─────────────┼────────────────┼──────────────┤
│ old_role │ old_role │ old_role       │ public        │ some_id_seq  │ SEQUENCE    │ USAGE          │ YES          │
└──────────┴──────────┴────────────────┴───────────────┴──────────────┴─────────────┴────────────────┴──────────────┘

Der Eigentümer eines Objekts verfügt automatisch über alle Berechtigungen. Daher beginnt pg_class.relacl Als NULL - bedeutet Standard Berechtigungen. Sobald dieser Eigentümer einer anderen Rolle Berechtigungen gewährt, wird seine eigene Berechtigung zusätzlich explizit eingegeben, sodass sie auch in den Ansichten des Informationsschemas angezeigt wird. Oder nter Angabe der Quelle :

Wenn die Spalte "Zugriffsrechte" für ein bestimmtes Objekt leer ist, bedeutet dies, dass das Objekt über Standardberechtigungen verfügt (dh die Spalte "Berechtigungen" ist null). Standardberechtigungen enthalten immer alle Berechtigungen für den Eigentümer und können je nach Objekttyp einige Berechtigungen für PUBLIC enthalten, wie oben erläutert. Das erste GRANT oder REVOKE für ein Objekt instanziiert die Standardberechtigungen (z. B. {miriam=arwdDxt/miriam}) Und ändert sie dann gemäß der angegebenen Anforderung.

Um nicht triviale Dinge zu debuggen, schaue ich mir im Allgemeinen lieber pg_catalog - Tabellen an, die die Hauptquelle der Wahrheit sind. pg_class.relacl in diesem speziellen Fall:

SELECT relnamespace::regnamespace, relname, relacl
FROM   pg_class
WHERE  relname = 'some_id_sequence';

Oder \z (Abkürzung für \dp) In psql :

\z some_id_sequence

Angenommen, old_role Ist der Eigentümer, sollten Sie Folgendes sehen:

{old_role=rwU/old_role,new_role=r/old_role} - nach GRANT SELECT...
{old_role=rwU/old_role,new_role=U/old_role} - nach GRANT USAGE ...
{old_role=rwU/old_role,new_role=rU/old_role} - nachdem beide gewährt wurden

Und NULL (leer in psql), bevor etwas gewährt wird.

Ihre hinzugefügte Ausgabe zeigt, dass new_role tatsächlich das SELECT-Privileg hat. Sie haben gerade die falsche Ansicht nachgeschlagen. Es scheint, als ob new_role keine Berechtigungen für das öffentliche Schema besitzt - die normalerweise standardmäßig an PUBLIC vergeben werden.


Nebenbei: IDENTITY Spalten in Postgres 11 oder höher vermeiden die Aufregung. Diese verwenden Sequenzen genauso gut, intern, aber implizit im Besitz der Spalte IDENTITY und mit den entsprechenden Berechtigungen automatisch. Dann benötigen Sie keine separaten Zuschüsse für Sequenzen. Sehen:

2