zusätzlicher Superuser

[Tobias Köhnlein]

Hallo,

ist es möglich, und wenn ja wie ist es möglich einen zusätzlichen User mit SYSDBA-gleichen Rechten anzulegen. (z.B. Felder in Tabellen ändern, wo SYSDBA oder ein anderer Benutzer Owner ist??)?

Vielen Dank für die Hilfe

Tobias

[Elke Sausy]

Ja, dass wüsste ich auch gerne mal.

Gruß Elk

[Klaus Hannsen]

Ich habe mal was drüber gelesen, finde leider den Beitrag im Forum nicht mehr.<br>
Der Lösungsanstaz besteht wohl darin eine Rolle mit dem Namen SYSDBA zu erstellen, <br>Create Role sysdba geht leider nicht, es geht wohl auf den Systemtabellen.<br> Herr Kosch
hat sich noch nicht darüber geäußert, ich bekomme da auch bloß Fehler

[Elke Sausy]

Hallo Klaus,

schön, dass sich wenigstens mal jemand dazu äußert. Das Problem scheint ja komplexer zu sein als es scheint.

Zu der Role: es geht ja eigentlich nicht um den Namen, sondern um die Rechte von SYSDBA. Deshalb ist es ja ganz egal, wie die Role nachher heißt.

Elke Saus

[Torsten Grundke]

Hallo,

der USER "SYSDBA" hat automatisch Zugriff auf alle Datenbanken des IB-Servers. Wenn jetzt in einer DB eine ROLE mit dem Namen SYSDBA angelegt wird kann der USER SYSDBA nicht mehr auf diese Datenbank zugreifen, d.h. der SYSDBA wird von dieser Datenbank ausgesperrt!

Tschüß

Torste

[Andreas Kosch]

Hallo,

der Benutzer SYSDBA spielt beim InterBase eine besondere Rolle, wobei der InterBase im Vergleich zu anderen SQL-Datenbanken weitere Beschränkungen voraussetzt (zum Beispiel darf ein normaler Benutzer sein Passwort nicht selbst ändern). Diese Einmaligkeit von SYSDBA sollte daher beibehalten werden.

Die einzige meiner Auffassung nach saubere Lösung für dieses Problem bildet das nach, was Microsoft im Fall des SQL Server 7/2000 macht. Anstelle des direkten Logins in die Datenbank (Benutzername und Passwort) greift der Benutzer mit den Rechten seines Benutzerkontos (Anmeldekonto beim Betriebssystem) auf die Datenbank zu. Somit bestimmt die Zugehörigkeit zu einer Betriebssystem-Benutzergruppe seine Datenbank-Rechte.

Im Fall des InterBase würde das so aussehen: Ein mit Delphi geschriebenes COM-Objekt greift mit dem normalen SYSDBA-Einstieg auf den InterBase zu. Die Clients greifen immer dann, wenn SYSDBA-Rechte benötigt werden, nur über dieses COM-Objekt auf den InterBase zu. Über die Roles des Betriebssystems (MTS bzw. COM+) kann ein NT-Benutzer bzw. eine NT-Benutzergruppe mit Rechten für die einzelnen Interface-Methoden dieses COM-Objekts versehen werden. Somit legt nur der Administrator des Domänen-Kontrollers fest, wer mit welchen Rechten auf dieses Hilfsobjekt (und somit mit den SYSDBA-Rechten) auf die Datenbank zugreifen darf. Da für jede einzelne Funktion eine Interface-Methode benötigt wird und jede Interface-Methode einzeln konfiguriert werden kann, erhält man eine Flexibilität, die mit den Datenbank-Roles allein niemals nachgebildet werden kann

[Gesine Kuhlmann]

Hi,

1)
An Andreas:
und zack, fällt Linux als DB-Server aus.

2)
an Elke:
Wozu sollte man denn eine zusätzlichen SYSDBA überhaupt benötigen ?? Wer mit SYSDBA-Rechten arbeitet, kann sich doch auch als SYSDBA anmelden.

Gruß
Gesin

[Andreas Kosch]

Hallo Gesine,

zu 1) <br>
Hier trennt sich die Spreu vom Weizen :-)

&#10

[Gesine Kuhlmann]

Hi Andreas,

Aber warum Heu fressen, wenn's doch Weizen gibt ?? ;-)

Gruß
Gesin

[Andreas Kosch]

Hallo Gesine,

nimms nicht persönlich. Dieser Unterschied zwischen Win32 und Linux untermauert nur meine These, dass heute ein Betriebssystem mehr sein muss als ein reiner Web-, Print- oder Fileserver. Und dieses Linux-Defizit wird ja auch ernsthaft von den Linux-Leute als solches erkannt. Es ist nur fraglich, ob angesichts der dort herrschenden Artenvielfalt dieser Mangel irgendwann beseitigt werden kann

[Gesine Kuhlmann]

Hi Andreas,

1)
So ganz ernst war mein Satz ja auch nicht gemeint ;-)

2)
Der Versuch Microsofts, einen einheitliche Applikationsschnittstelle zu schaffen, ist auch ein guter Ansatz. So war es schon immer Microsofts Problem gute theoretische Ansätze aufzugreifen und in einem Beta-Zustand unters Volk zu bringen. Danach muss sich jeder jahrelang mit all den Unzulänglichekeiten ( miese Performance, massive Sicherheitsprobleme, Unmengen von Versionsständen um nur einige zu nennen ) herumärgern und darauf warten, bis MS sich herablässt Fehler zu beseitigen.

3)
Über das was Betriebssysteme mitbringen müssen oder die darauf laufenden Applikationen, kann man durchaus geteilter Meinung sein. Ich erwarte von einem Betriebssystem in erster Linie zwei Dinge: 1. Stabilität 2. Datensicherheit.
Diesbzgl. muss man zu Windows wohl nichts weiter sagen...

4)
Ich gehe davon aus, dass du ( als Entwickler ) mit <i>mehr</i> in erster Linie Techniken a' la COM meinst. Hab' ich ein zugenageltes System bin ich darauf zwangsläufig angewiesen. Hab' ich den Sourcecode der Zielapplikation vorliegen, komme ich auch ohne derartige Funktionalitäten recht leicht zum Ziel.

5)
Was die Artenvielfalt angeht, hat MS doch längst schon überholt. Und MS arbeitet kräftig daran diesen Fortschritt weiter auszubauen. Die Folgeverion von XP liegt doch schon in der Schublade. Aus bekannten Gründen ( Kosten, kaum Vorteile ) ist es auch viel schwerer einen Versionsstand zu konsolidieren. Da wird die breite Installationsbasis schon zum Fluch. Innerhalb der einzelnen Versionen gibt's dann nochmal das eine odere andere, was sich unterscheidet. Genannt sei nur DDE, OLE, COM, COM+, DCOM. Alle verfolgen das gleiche Ziel. Keine funktioniert bis heute wirklich angemessen.

6)
Darum bin ich der Meinung, dass Microsoft genau das passieren wird, was ehemals Macintosh pasiert ist. Dadurch das der Unterschied immer geringer wird ( ich kenne z.B. den einen oder anderen Nutzer, der ne' Windows-Oberfläche nicht von KDE unterscheiden kann ), entscheiden die Kosten über den Einsatz des Betriebssystems. Da können MS-Strategen Milchmädchenrechnungen postulieren soviel sie wollen. Ein gutes Betriebssystem, das ich ohne Lizenzgebühren einsetzen darf, ist immer günstiger als andere. In diesem Fall kann MS noch nicht mal durch geschicktes Aufkaufen einen Konkurrenten ausser Gefecht setzen.

7)
Also stimmen wir im microsft'schen Sinne 'Die Internationale' an und harren der Dinge die da kommen mögen ;-)

Gruß
Gesin

[Klaus Hannsen]

das eigentliche Problem besteht doch darin, einen User zu schaffen der die selben Rechte hat wie SYSDBA, es sollte nicht darum gehen, über andere Mittel ( DCOM....) auf die Datenbank zuzugreifen.
Gibt es denn absulut keine andere Möglichkeit das Problem auf einem <b> einfachem </B> Weg zu lösen? Manchen würde es ja schon reichen, den User SYSDBA umzubenennen. Das größte Problem was ich damit habe, ist meine Application bei einem Kunden zu Installieren, der WIN95,98 im einsatz hat, und einiges über SQL weiß. ER installiert sich IBConsole, holt sich von eienem anderen Rechner die Passwortdatei vom IB und schon habe ich viele Probleme....

[Torsten Grundke]

Hallo Klaus,

sobald der Anwender sich mit den Systemtabellen des IB-Servers auskennt und physikalischen Zugriff auf den Computer hat auf dem der IB-Server installiert ist, sieht es ganz finster aus.

Falls jemand einen Weg kennt einen User die Select-Rechte an der Systemtabelle RDB$USER_PRIVILEGES zu entziehen, dann würde es einen Hoffnungsschimmer geben.

Den Zugriff von SYSDBA auf die eigene Datenbank kann man wie bereits gesagt mit einer ROLE mit dem Namen "SYSDBA" verhindern (insert into RDB$Roles (RDB$ROLE_NAME, RDB$OWNER_NAME) VALUES ('SYSDBA','irgend_ein_user') - falls der zweite Parameter ein leerer String ist kann die ROLE SYSDBA nicht mehr gelöscht werden). Damit hat man dem Anwender einige Steine in den Weg gelegt, mehr aber auch nicht.

Tschüß

Torste

[Gesine Kuhlmann]

Hi,

Wenn man einen SQL-Server einsetzt und nicht will, dass der Eigentümer über die Struktur Bescheid weiss, hat man prinzipiell zum falschen Werkzeug gegriffen. Dazu gibt's schon eine Diskussion im Thread <i>Datenbanken/Interbase/Datensicherheit</i>.

Gruß
Gesin

[Klaus Hannsen]

Hallo Gesine
<br>
Das sehe ich aber anderst, gerade weil ich einen Schutz vor dem Anwender aufbauen will, setze ich einen SQL Server ein. Oder ist deine Bemerkung speziell auf den Interbase zugeschnitten