Zugriff auf vorhandene Tabellen in der DB

[Alfons Wiesmeier]

hallo,

hab das problem, dass wenn ich einen neuen user (trotz entsprechenden rechten) anlege, dass dieser dann auf keine einzige tabelle des entsprechenden DB_Service hat....

Hat jemand ne Ahnung, wie ich die entsprechenden Tabellen dem user unterordnen (also den Zugriff ermöglichen) kann???

danke

gruß
c.

[Steven Troll]

Hallo Alfons,

deine Fehlerbeschreibung ist etwas dürftig. Kann er sich denn connectieren ? Wenn nicht, braucht er das connect Recht (grant connect to username). Ansonsten lege bitte eine Rolle mit den entsprechenden Rechten an und weise dem User die Rolle zu (Grant Role1 to username). Wenns nicht klappt, bitte mit Fehlermeldung nochmal hier posten.

MfG Steve

[Alfons Wiesmeier]

hallo,

also erstmal danke für die bemühungen....

selbstverständlich kann er connectieren...

nur wenn ich select * from tab mache heisst es
0 tabellen gefunden...

und auch im schema manager sind dem angelegtem user keine tabellen zugeordnet...
(die rechte für select, crate und alter table usw. hat er; selbst wenn ich dem user die rolle dba zuweise hat er keinen zugriff auf irgendwelche tabellen

danke

gruß
c

[Matthias Fichte]

Hi, Keine Rechte<BR>
Jeder Benuter in Oracle hat Standardmaessig nur Rechte auf<BR>
seine Objekte in seinem Schema.<BR>
Übergreifend muessen Rechte vom Besitzer vergeben werden.<BR>
Bsp.<BR>
User Scott besitzt Tabelle EMP (Oracle standard User für Demos)<BR>
User ADAMS soll auf Tabelle EMP von SCOTT zugreifen.<BR>
Also miss SCOTT die Tabelle fuer ADAMS freigeben<BR>
CONNECT SCOTT/TIGER@TNSNAME<BR>
GRANT SELECT ON EMP TO ADAMS;<BR>

Hoffe das hilft dir<BR>
Mattias<BR>
Nun kann ADAMS auf SCOTT.EMP zugreifen<BR>
Allerding nuss das Schema mit angegeben werden (SCOTT.EMP)<BR&gt

[Uschi Blanz]

Hallo,

wenn Du Dir den Qualifier(Schema) für die Tabelle sparen willst, damit Du Skripte, etc nicht alle anpassen musst, leg mit dem neuen User noch Synonyme an. z.B.:

create synonym ADAMS.EMP FOR SCOTT.EMP;

danach kann ADAMS mit select * from emp; das gleiche sehen wie SCOTT.

Gruß
Usch

[Alfons Wiesmeier]

hallo,

sorry, bin die letzten tage nicht dazu gekommen...

also vielen dank für die tipps, hat funktioniert -> muchas gracias...

eine frage dazu hätte ich noch (vielleicht weiss es ja jeman auf anhieb)

Ist es irgendwie möglich, dass ich einen neuen Benutzer anlege und dieser dann auch gleich zugriff auf alle tabellen eines anderen benutzers hat?

danke

gruß
c

[Uschi Blanz]

Hallo ,

Du kannst die Berechtigung für alle Tabellen eines Benutzers in eine Rolle packen. Danach braucht jeder neue Benutzer, der auf diese Tabellen zugreifen soll nur noch die Berechtigung für die Rolle:

<PRE>
create role RolleScott;
grant select, insert, update, delete on Scott.EMP to RolleScott;
create NeuerBenutzer;
grant RolleScott to NeuerBenutzer;
</PRE>

die Synonyme sind damit allerdings nicht drin. Wenn Du die nicht für jeden neuen Benutzer separat anlegen willst, solltest Du als Tabellen-Owner angemeldet public synonyms vergeben:

create public synonym EMP for SCOTT.EMP;

Gruß
Usch

[Alfons Wiesmeier]

Again:

muchas gracias

christop

[meute]

Hallo,

ich muss den Thread noch mal rausziehen, weil ich vor dem gleichen Problem stehe.

Du kannst die Berechtigung für alle Tabellen eines Benutzers in eine Rolle packen. Danach braucht jeder neue Benutzer, der auf diese Tabellen zugreifen soll nur noch die Berechtigung für die Rolle:

create role RolleScott;
grant select, insert, update, delete on Scott.EMP to RolleScott;
create NeuerBenutzer;
grant RolleScott to NeuerBenutzer;

die Synonyme sind damit allerdings nicht drin. Wenn Du die nicht für jeden neuen Benutzer separat anlegen willst, solltest Du als Tabellen-Owner angemeldet public synonyms vergeben:

create public synonym EMP for SCOTT.EMP;

Unser Schema Owner hat ~6000 Tabellen.
Ich möchte nun einen User anlegen, der SELECT-Zugriff (mit SQLPlus oder TOAD) auf alle Tabellen des Schema Owner hat.
Die Lösung, zuerst eine Rolle anzulegen und diese dann dem neuen User zuzuweisen, finde ich nicht schlecht.

Aber wie kann man beim anlegen der Rolle mit "grant select..." alle ~6000 Tabellen ansprechen?


Das gleiche wird dann ja auch für die Synonyme benötigt.
Auch da muss man ~6000 Synonyme anlegen.

Wie kann das global für alle Tabellen gemacht werden?


Und dann noch eine Frage.
Wenn man das Recht und die Synonyme auf die Tabellen anlegt, ändern sich dann Eigenschaften an den Tabellen?
Nicht dass es hinterher mit der Anwendung Probleme gibt, die die Oracle-DB nutzt.

Danke.


Gruß
meute

[Wernfried]

Hallo

Wenn du ein Synonym erzeugts ändert sich an der Tabelle rein gar nichts.

Für die Zuteilung der Rechte kannst du ein PL/SQL Script nehmen:
[HIGHLIGHT=plsql]
CREATE ROLE ROLE_ALLOW_ALL NOT IDENTIFIED;

BEGIN
FOR aTable IN (SELECT * FROM DBA_TABLES WHERE owner = 'MY_SCHEMA') LOOP
EXECUTE IMMEDIATE 'GRANT SELECT, DELETE, INSERT, UPDATE ON MY_SCHEMA.'||aTable.TABLE_NAME||' TO ROLE_ALLOW_ALL';
EXECUTE IMMEDIATE 'CREATE OR REPLACE PUBLIC SYNONYM '||aTable.TABLE_NAME||' FOR MY_SCHEMA.'||aTable.TABLE_NAME;
END LOOP;
END;
[/HIGHLIGHT]


Eine andere Methode wäre wenn du der Rolle direkt das Recht für alle Tabellen gibst. Unter Umständen habt ihr dann aber ein Problem mit Sicherheit der Daten.
[HIGHLIGHT=sql]
GRANT SELECT ANY TABLE TO ROLE_ALLOW_ALL;
GRANT UPDATE ANY TABLE TO ROLE_ALLOW_ALL;
...
[/HIGHLIGHT]


Wenn du die Rechte über eine Rolle vergibst, gibt es einen kleinen Fallstrick in den jeder PL/SQL Entwickler einaml in seinem Leben hinein tappt:
Innerhalb eines PL/SQL Blocks gelten (per default) nur die Rechte welche man direkt bekomment hat. Rechte welche man über eine Rolle bekommen hat gelten nicht im PL/SQL, sondern nur im SQL.



Gruss

[defo]

Du könntest so vorgehen:

[HIGHLIGHT=SQL]
select TABLE_NAME from user_tables;
Select 'Grant select, insert, update on '||TABLE_NAME||' to [newrole|newuser];' from user_tables;
[/HIGHLIGHT]

Das ganze ggF. per where clause einschränken oder in mehreren Schritten aufbauen. 'From user_tables ' bedingt, dass das Select im Kontext des "Ausgangsusers" durchgeführt wird.
Das Ergebnis als Script speichern und ausführen, für Synonyms analog.

Effekte sind nicht zu erwarten (auf Oracle Ebene), denn dafür ist die ganze Masche ja gedacht. Probleme können sich ergeben, wenn im Zugriffscode der Anwendung unsauber gearbeitet wurde (Festes, also falsches Schema, etc.)

[dbwizard]

Hallo ,

Ich würd es mir zwei mal überlegen, ob ich wirklich 6000 Synomyme anlegen will. Warum nicht einfach (Nebst der Rolle mit den entsprechenden Berechtigungen) nicht einfach ein

ALTER SESSION SET CURRENT_SCHEMA=SCHEMA_DES_OWNERS

absetzten, z.b. via Logon Trigger (Session) oder über die Applikation ?



Grüsse

[defo]

Ich würd es mir zwei mal überlegen, ob ich wirklich 6000 Synomyme anlegen will. Warum nicht einfach (Nebst der Rolle mit den entsprechenden Berechtigungen) nicht einfach ein

ALTER SESSION SET CURRENT_SCHEMA=SCHEMA_DES_OWNERS

absetzten, z.b. via Logon Trigger (Session) oder über die Applikation ?

Das ist eine schöne Möglichkeit, setzt aber voraus, dass "der Client" das auch alles verdauen kann. Ich hatte bspw. Probleme, wenn auf diesem Weg auch Views oder Selects mit DB Links angesprochen werden. Würde ich nur machen, wenn ich alle verwendeten Datenzugriffsformen mal in einem Test erfolgreich durchgekaut habe.
Ich bin auch kein Freund von Synonymen und würde vielleicht sogar noch ein eigenes Interface Schema mit Views auf die Originaltabellen vorziehen. Sowas hab ich aber noch nie in einem Produktivsystem gemacht.

[meute]

Hallo Wernfried,

danke für Deine Antwort.

Wenn du ein Synonym erzeugts ändert sich an der Tabelle rein gar nichts.

Und wie ist das bei der Zuteilung der Rechte?
Ändert sich da was (u.U. systemrelevantes) an den Tabellen?


Dieses Recht bekommt bei uns jeder User.
Da scheint der Software-Hersteller kein Problem mit der Sicherheit der Daten zu sehen.
[HIGHLIGHT=sql]GRANT SELECT ANY TABLE TO USER;[/HIGHLIGHT]
Das alleine reicht aber wohl nicht, um in SQLPlus/Toad Zugriff auf die Tabellen zu haben?


EDIT1:
Sehe gerade, dass der Thread ja schon 2 Seiten hat und lese nun auch die Antworten von "defo" und "dbwizard".


EDIT2:
Um die Sache vll. zu vereinfachen ist hier das Script, mit dem bei uns die User angelegt werden.
Davon soll einer SELECT-Zugriff auf die Tabellen und Views des Schema-Owner erhalten (mit SQLPlus bzw. Toad).
Welche Rechte fehlen dazu?

[HIGHLIGHT=sql]
DROP USER TEST_ADMIN CASCADE;

CREATE USER TEST_ADMIN
IDENTIFIED BY "xyz"
DEFAULT TABLESPACE USER_SCHEMA_OWNER
TEMPORARY TABLESPACE TEMP
PROFILE DEFAULT
ACCOUNT UNLOCK;
-- 9 Roles for TEST_ADMIN
GRANT ROL1 TO TEST_ADMIN;
GRANT ROL2 TO TEST_ADMIN;
GRANT ROL3 TO TEST_ADMIN;
GRANT ROL4 TO TEST_ADMIN;
GRANT CONNECT TO TEST_ADMIN;
GRANT EVERYONE TO TEST_ADMIN;
GRANT ROL5 TO TEST_ADMIN;
GRANT ROL6 TO TEST_ADMIN;
GRANT RESOURCE TO TEST_ADMIN;
ALTER USER TEST_ADMIN DEFAULT ROLE ALL;
-- 2 System Privileges for TEST_ADMIN
GRANT UNLIMITED TABLESPACE TO TEST_ADMIN;
GRANT SELECT ANY TABLE TO TEST_ADMIN;
-- 1 Tablespace Quota for TEST_ADMIN
ALTER USER TEST_ADMIN QUOTA UNLIMITED ON USER_SCHEMA_OWNER;
-- 3 Object Privileges for TEST_ADMIN
GRANT SELECT ON SYS.V_$PARAMETER TO TEST_ADMIN;
GRANT SELECT ON SYS.V_$SESSION TO TEST_ADMIN;
GRANT SELECT ON SYS.V_$TRANSACTION TO TEST_ADMIN;[/HIGHLIGHT]


Gruß
meute

[defo]

Und wie ist das bei der Zuteilung der Rechte?
Ändert sich da was (u.U. systemrelevantes) an den Tabellen?

Es ändert sich nichts.

Da scheint der Software-Hersteller kein Problem mit der Sicherheit der Daten zu sehen.
[HIGHLIGHT=sql]GRANT SELECT ANY TABLE TO USER;[/HIGHLIGHT]

Dann sieht er das recht locker.
[/QUOTE]

Das alleine reicht aber wohl nicht, um in SQLPlus/Toad Zugriff auf die Tabellen zu haben?

Wieso? Gibt es Fehler?
Mit diesen Rechten kannst DU alles außer SYS Tabellen lesen.

Ist Dir das SCHEMA/USER Zugriffs Konzept bei Oracle klar?
Nur mal als Stichwort: Eine erteilte Berechtigung erspart es Dir nicht, korrekt auf das Objekt zuzugreifen (richtige Benennung). Aus Beqeumlichkeit nimmt man hier dann gerne SYNONYMS.