ich: Oracle: Rechte für zukünftig erzeugte Objekte vergeben

Tach.

Kann man in Oracle Rechte für Objecte vergeben, die es erst später mal geben wird?

Beispiel - was natürlich nicht geht.

grant select on project.ek_* to sales;

Bedeutet also ich will dem User Sales das Select Recht auf alles geben, was mit "project.ek_" beginnt und das soll auch für später angelegte Objekte gelten.

Wenn es zum Beispiel project.ek_produkte gibt, dann soll sales das recht dazu bekommen. Wird irgendwann mal project.ek_lagerbestand angelegt, dann soll sales auch das benutzen dürfen, obwohl es zur Zeit der Rechtevergabe noch nicht existiert hat.

  1. Nachtrag:
    Es soll vor allem auch für Views funktionieren und Oracle 9i so wie 10g sind gefragt.

  2. Hallo,

    Objekte bei Oracle (wie auch bei anderen DBMS) sind meist Teil eines Namensraumes, oft "Schema" genannt. Diese Schemata sind für gewöhnlich ebenfalls Objekte auf denen man Rechte vergeben kann. Diese werden dann auch für gewöhnlich auf alle Objekte in diesem Schema vererbt. D.h. ein

    GRANT SELECT ON project to sales;

    könnte durchaus schon alles bewirken, was du benötigst. Du kannst ja mit dem grafischen Verwaltungstool für Oracle dich auf das Schema oder den Tablespace "projekt" durchnavigieren und die dafür die Sicherheitseinstellungen anschauen.

    Da ich aktuell nicht mit Oracle zu tun habe, kann ich dir die Lösung nicht auf dem Silbertablett servieren.

    Cheerio,
    Frank

    1. Ok, ich präzisire das ganze mal etwas mehr.

      Es gibt ein Schema eines Benutzers und es gibt einen weiteren Benutzer. Benutzer Nr. 2 soll nur Tabellen und Views von Benutzer 1 sehen können, die mit einem bestimmten Prefix (z.B. ek_) beginnen und da dann aber auch die, die Zukünftig noch angelegt werden.

      1. Hallo "ich",

        Es gibt ein Schema eines Benutzers und es gibt einen weiteren Benutzer. Benutzer Nr. 2 soll nur Tabellen und Views von Benutzer 1 sehen können, die mit einem bestimmten Prefix (z.B. ek_) beginnen und da dann aber auch die, die Zukünftig noch angelegt werden.

        Wie wäre es der Einfachheit halber, wenn du statt des Präfixes ein normales Schema "EK" erzeugst, auf welchem die Benutzer dann ihre jeweilig benötigten Rechte haben. Benutzer 1 kann ja Eigentumsrechte auf diesem Schema "EK" haben. Ein plausibles Sicherheits/Zugriffs-Modell zu erlauben ist einer der Zwecke von Schemas.

        Gruss, ciao, Frank

        1. Hi.

          Wie wäre es der Einfachheit halber, wenn du statt des Präfixes ein normales Schema "EK" erzeugst, auf welchem die Benutzer dann ihre jeweilig benötigten Rechte haben. Benutzer 1 kann ja Eigentumsrechte auf diesem Schema "EK" haben. Ein plausibles Sicherheits/Zugriffs-Modell zu erlauben ist einer der Zwecke von Schemas.

          Natürlich könnte man ein Schema erzeugen, wo die Dinge drinn sind, die "öffentlich" sein sollen. Problem: Benutzer 1 kann nicht beigebracht werden diese Objecte in einem anderen Schema zu erstellen. Grund:
          Benutzer 1 ist kein echter User, sondern eine Software, wo das Schema fest im Programm eingetragen wurde (irgendwo im Sourcecode). Darunter werden dann alle Tabellen, Packages, Views usw. abgelegt.

          Benutzer 2 ist dann der echter User, der da z.B. nur bestimmte Views sehen soll. Dieser war nicht eingeplant und muss nun nachträglich und nur Ausnahmsweise eingerichtet werden. Er wird daher auch nicht Teil des fertigen Produkts werden, sondern ist nur für die Partnerfirma bei einer einzelen Installation gedacht.

          MfG
          ich