70866
02.03.2010, aktualisiert am 03.03.2010
7687
9
0
Oracle 10G drop table Recht wegnehmen
Ein user hatte die Rolle dba.
Die habe ich weggenommen und trotzdem hat der user immer noch drop table Recht
Der Server ist 10.2.0.1.0 - zwar nicht das Allerneueste, aber sonst läuft er.
Der User hat folgende Rechte:
unlimited tablespace
select any table
insert any table
update any table
und diese Rolle:
Connect
Der User kann kein Create table mehr machen setidem er nicht mehr DBA ist - warum zum Henker kann er IMMER noch drop table machen?
Ist das ein Bug oder versteh ich was an der Rechtevergabe falsch?
Wenn ich das Recht "create any table" hinzufüge dann kann der User ein "create table (nr int, name char(10)); ausführen
wenn ich das "Create any table" wegnehme, dann kann er das nicht mehr.
Was mich stutzig macht ist daß es ein Recht mit dem Namen "drop any table" gibt, das der User nicht hat.
Die habe ich weggenommen und trotzdem hat der user immer noch drop table Recht
Der Server ist 10.2.0.1.0 - zwar nicht das Allerneueste, aber sonst läuft er.
Der User hat folgende Rechte:
unlimited tablespace
select any table
insert any table
update any table
und diese Rolle:
Connect
Der User kann kein Create table mehr machen setidem er nicht mehr DBA ist - warum zum Henker kann er IMMER noch drop table machen?
Ist das ein Bug oder versteh ich was an der Rechtevergabe falsch?
Wenn ich das Recht "create any table" hinzufüge dann kann der User ein "create table (nr int, name char(10)); ausführen
wenn ich das "Create any table" wegnehme, dann kann er das nicht mehr.
Was mich stutzig macht ist daß es ein Recht mit dem Namen "drop any table" gibt, das der User nicht hat.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Kommentar vom Moderator Biber am 03.03.2010 um 11:21:04 Uhr
Verschoben von "Windows-weiss-nich-genau" nach "Datenbanken".
Content-ID: 137215
Url: https://administrator.de/contentid/137215
Ausgedruckt am: 23.11.2024 um 08:11 Uhr
9 Kommentare
Neuester Kommentar
Hallo,
ich habe das auch erst nicht glauben wollen, aber es ist tatsächlich so. Ein User kann immer eigene Tabellen droppen.
Um das zu verhindern gibt es (mindestens) zwei Möglichkeiten:
1. Ein Rechtesystem entwickeln, in welchem die User keine "eigenen" Tabellen besitzen, sondern nur auf "fremde" Tabellen zugreifen.
2. Ein Trigger auf die Tabelle legen, der ein Löschen abfängt (exception trigger). siehe auch
Gruß René
ich habe das auch erst nicht glauben wollen, aber es ist tatsächlich so. Ein User kann immer eigene Tabellen droppen.
Um das zu verhindern gibt es (mindestens) zwei Möglichkeiten:
1. Ein Rechtesystem entwickeln, in welchem die User keine "eigenen" Tabellen besitzen, sondern nur auf "fremde" Tabellen zugreifen.
2. Ein Trigger auf die Tabelle legen, der ein Löschen abfängt (exception trigger). siehe auch
Gruß René
Moin shadowmaster,
ja nee, das ist eigentlich kein Fehler in der Matrix, sondern soll und muss so sein.
Auf jedes Datenbankobjekt, das neu geschaffen/created werden kann, muss natürlich der OWNER volle (und im ersten Schritt alleinige) Rechte haben.
Und zu den anfänglich "alleinigen" Rechten gehört natürlich auch das DROP.... hat ja sonst keiner (außer DBAs oder Stefan Raab).
Der Fehler im System war ja bei genauerer Betrachtung, dass dieser von dir genannte User tatsächlich "eigene" Tabellen, ein eigenes Schema anlegen durfte.
Das ist Grütze, Unsinn.... der normale Oracle-Rechte hat nur die geGRANTeten Rechte auf Tabellen/Views eines Schemas zu haben, das nicht ihm "gehört".
Oder greift über (public) Synonyme zu.
Und die Tabellen, die er ggf. "für sich" anlegen kann - na ja, die darf er im TEMP-Tablespace anlegen und dort spielen.
Was sich Oracle anlasten ließe ist nur, dass es keine offizielle schnelle Mimik gibt für ein "Change/Rename schema owner for all database objects"..
Richtig und supportet wäre eigentlich nur ein Export altes Schema/Drop/Import als neues Schema.
Oder eben (unsupportet, schnell und bäh bäh bäh) direktes Ändern des OWNERs/des Schemanamens im Data Dictionary:
Bolle97s Workaround über Drop-Stop-Trigger.... ja nee.... als Dauerlösung will das auch niemand wirklich in einer produktiven DB haben.
Dann lieber einmal statt Mittagsschläfchen Export als altes/Import als neues Schema und in Zukunft solche Aktionen vermeiden.
Grüße
Biber
ja nee, das ist eigentlich kein Fehler in der Matrix, sondern soll und muss so sein.
Auf jedes Datenbankobjekt, das neu geschaffen/created werden kann, muss natürlich der OWNER volle (und im ersten Schritt alleinige) Rechte haben.
Und zu den anfänglich "alleinigen" Rechten gehört natürlich auch das DROP.... hat ja sonst keiner (außer DBAs oder Stefan Raab).
Der Fehler im System war ja bei genauerer Betrachtung, dass dieser von dir genannte User tatsächlich "eigene" Tabellen, ein eigenes Schema anlegen durfte.
Das ist Grütze, Unsinn.... der normale Oracle-Rechte hat nur die geGRANTeten Rechte auf Tabellen/Views eines Schemas zu haben, das nicht ihm "gehört".
Oder greift über (public) Synonyme zu.
Und die Tabellen, die er ggf. "für sich" anlegen kann - na ja, die darf er im TEMP-Tablespace anlegen und dort spielen.
Was sich Oracle anlasten ließe ist nur, dass es keine offizielle schnelle Mimik gibt für ein "Change/Rename schema owner for all database objects"..
Richtig und supportet wäre eigentlich nur ein Export altes Schema/Drop/Import als neues Schema.
Oder eben (unsupportet, schnell und bäh bäh bäh) direktes Ändern des OWNERs/des Schemanamens im Data Dictionary:
Bolle97s Workaround über Drop-Stop-Trigger.... ja nee.... als Dauerlösung will das auch niemand wirklich in einer produktiven DB haben.
Dann lieber einmal statt Mittagsschläfchen Export als altes/Import als neues Schema und in Zukunft solche Aktionen vermeiden.
Grüße
Biber
hey, danke! Hat mir sehr geholfen. Vielleicht spendiert mein Brötchengeber nun endlich mal nen Oracle DBA Kurs 
Bis vor 2 Jahren hatten wir den (damals nur europäischen) Kunden einfach gesagt, supportet euer Oracle doch selbst, wir machen das nicht. ODer stellt auf MS SQL Server um da können wir dann helfen
Dann globalisierte sich alles, die USA und Asien kam dazu - und speziell den Chinesen ist das mit dem Oracle nicht auszureden und die wollen unbedingt wissen, was wir da raten.
Noch so ne Frage: wenn ich einen Oracle-User anlege, und dem per Grant die Rechte auf das eigentlich benötigte Schema geb - muß ich dann trotzdem die Namen des "fremden" Schemas voranstellen oder sieht der User die Tabellen dann automatisch?
Also, das Schema gehört A und enthält eine Tabelle users
B hat ein Grant select, update, insert, delete on A erhalten.... muß die genaue Syntax noch mal nachschlagen....
also ein select * from A.users oder kann ich ein select * from users machen?
Bis vor 2 Jahren hatten wir den (damals nur europäischen) Kunden einfach gesagt, supportet euer Oracle doch selbst, wir machen das nicht. ODer stellt auf MS SQL Server um da können wir dann helfen
Dann globalisierte sich alles, die USA und Asien kam dazu - und speziell den Chinesen ist das mit dem Oracle nicht auszureden und die wollen unbedingt wissen, was wir da raten.
Noch so ne Frage: wenn ich einen Oracle-User anlege, und dem per Grant die Rechte auf das eigentlich benötigte Schema geb - muß ich dann trotzdem die Namen des "fremden" Schemas voranstellen oder sieht der User die Tabellen dann automatisch?
Also, das Schema gehört A und enthält eine Tabelle users
B hat ein Grant select, update, insert, delete on A erhalten.... muß die genaue Syntax noch mal nachschlagen....
also ein select * from A.users oder kann ich ein select * from users machen?
Moin Schattenmeister,
lies doch noch mal ggf. über eine Suchmaschine ein paar Sätze zum Thema "Synonyme" im Oracle-Kontext.
Das sollte deine Fragen beantworten.
Grüße
Biber
lies doch noch mal ggf. über eine Suchmaschine ein paar Sätze zum Thema "Synonyme" im Oracle-Kontext.
Das sollte deine Fragen beantworten.
Grüße
Biber
Zitat von @Biber:
> Und die Tabellen, die er ggf. "für sich" anlegen kann - na ja, die darf er im TEMP-Tablespace anlegen und dort
spielen.
> Und die Tabellen, die er ggf. "für sich" anlegen kann - na ja, die darf er im TEMP-Tablespace anlegen und dort
spielen.
Im TEMP Tablespace ? Wohl eher nicht.
Gruss
Zitat von @70866:
also ein select * from A.users oder kann ich ein select * from users machen?
Also, das Schema gehört A und enthält eine Tabelle users
B hat ein Grant select, update, insert, delete on A erhalten.... muß die genaue Syntax noch mal nachschlagen....also ein select * from A.users oder kann ich ein select * from users machen?
Hallo,
Die einfachste Methode dürfte sein, dem User beim Logon ein alter session set current_Schema='mySchema' zu geben, so musst du nicht mit Synonymen arbeiten und es entfällt ein Schicht, welche du erstellen / warten musst
Gruss
Moin db-wizard,
meinst du, das wäre gemein?
Ich biete meinen DAUs das immer an, dass sie ja ihre Test-Tabellen da anlegen können...
Und die nicken immer erfreut und Reklamationen sind sehr, sehr selten... *g
Aber nächstes Mal verwende ich auch wieder <Ironie>-Tags.
Grüße
Biber
meinst du, das wäre gemein?
Ich biete meinen DAUs das immer an, dass sie ja ihre Test-Tabellen da anlegen können...
Und die nicken immer erfreut und Reklamationen sind sehr, sehr selten... *g
Aber nächstes Mal verwende ich auch wieder <Ironie>-Tags.
Grüße
Biber
moin,
ich werd mich ab Montag mal schlaugooglen....
ich werd mich ab Montag mal schlaugooglen....
also, ein Alter session kann ich nicht machen - auch Synonyme sind nicht die richtige Wahl.
Ich hab was viel besseres gefunden:
einen Trigger der das Drop Event abfängt.
Muß in jedem Schema bzw. für jeden User separat angelegt werden.
Unsere Tabellen fangen alle mit einem LC_ an und somit ist es relativ einfach, ein Drop table zu verhindern.
Genaugenommen gehts hier nicht um drop table sondern darum was gedropt wird. Legt man den Trigger im Schema SYS ab, dann kann ich beispielsweise auch keine User mehr löschen die mit LC_ anfangen, denn es ist egal ob ein drop table, drop index oder drop sonstwas abgefangen werden soll.
create TRIGGER TrgDropTablePrevention
BEFORE DROP
ON DATABASE
DECLARE
BEGIN
IF Ora_Dict_Obj_Name like 'LC_%'
THEN
Raise_Application_Error(
-20001,
'For Dropping This Table - tabliig usgah bolohgui !');
END IF;
END;
Vielleicht gibts noch ne geschicktere Lösung, aber diese hier ist schon ganz gut.
Ich hab was viel besseres gefunden:
einen Trigger der das Drop Event abfängt.
Muß in jedem Schema bzw. für jeden User separat angelegt werden.
Unsere Tabellen fangen alle mit einem LC_ an und somit ist es relativ einfach, ein Drop table zu verhindern.
Genaugenommen gehts hier nicht um drop table sondern darum was gedropt wird. Legt man den Trigger im Schema SYS ab, dann kann ich beispielsweise auch keine User mehr löschen die mit LC_ anfangen, denn es ist egal ob ein drop table, drop index oder drop sonstwas abgefangen werden soll.
create TRIGGER TrgDropTablePrevention
BEFORE DROP
ON DATABASE
DECLARE
BEGIN
IF Ora_Dict_Obj_Name like 'LC_%'
THEN
Raise_Application_Error(
-20001,
| Ora_Dict_Obj_Name |
END IF;
END;
Vielleicht gibts noch ne geschicktere Lösung, aber diese hier ist schon ganz gut.
