4
MS SQL Server client stürzt ab wenn kein db owner
Hi,
ich rätsel gerade an einer Anwendung herum, wo unsere Entwickler stets sagen daß db_owner Rechte auf dem MS SQL Server benötigt werden.
Nur ist das so nicht ganz richtig - sie erstellt Tablelen (ddladmin) sie liest und schreibt daten (datareader und datawriter)
Dazu erstellt sie Indizes (ddladmin?) und führt stored procedures aus.
Nur wenn ich db_owner wegnehme kreige ich eine nichtssagende, dafür extrem lange Fehlermeldung, ein openrecordset im SQLDataReader des SQL Server Native Client 11 wäre fehlgeschlagen.
Das letzte Lebenszeichen im SQL Server Profiler war ein exec auf eine stored procedure
Danach stürzt mir die Anwendung ab, sie wirft 5 kB an Text der im wesentlichen folgendes sagt:
Das "Movenext" in einem Recordset hat fehlgeschlagen bzw das Erstellen eines Cursors dazu.
Aber was an dem Vorgang benötigt mehr als eine Kombination aus
db_datareader
db_datawriter
db_ddladmin
db_securityadmin
db_accessadmin
db_backupadmin
Im SQL Server Log seh ich nicht mal bei aktiviertem C2 Audit irgenwelche Probleme, dort ist das letzte Lebenszeichen ein "Login succeeded" für die Applikation
Ich kann die Frage auch umdrehen:
Was kann der db_owner, was die anderen Rechte nicht können?
@admins warum sind Unterstriche in Titeln nicht erlabt?
ich rätsel gerade an einer Anwendung herum, wo unsere Entwickler stets sagen daß db_owner Rechte auf dem MS SQL Server benötigt werden.
Nur ist das so nicht ganz richtig - sie erstellt Tablelen (ddladmin) sie liest und schreibt daten (datareader und datawriter)
Dazu erstellt sie Indizes (ddladmin?) und führt stored procedures aus.
Nur wenn ich db_owner wegnehme kreige ich eine nichtssagende, dafür extrem lange Fehlermeldung, ein openrecordset im SQLDataReader des SQL Server Native Client 11 wäre fehlgeschlagen.
Das letzte Lebenszeichen im SQL Server Profiler war ein exec auf eine stored procedure
Danach stürzt mir die Anwendung ab, sie wirft 5 kB an Text der im wesentlichen folgendes sagt:
Das "Movenext" in einem Recordset hat fehlgeschlagen bzw das Erstellen eines Cursors dazu.
Aber was an dem Vorgang benötigt mehr als eine Kombination aus
db_datareader
db_datawriter
db_ddladmin
db_securityadmin
db_accessadmin
db_backupadmin
Im SQL Server Log seh ich nicht mal bei aktiviertem C2 Audit irgenwelche Probleme, dort ist das letzte Lebenszeichen ein "Login succeeded" für die Applikation
Ich kann die Frage auch umdrehen:
Was kann der db_owner, was die anderen Rechte nicht können?
@admins warum sind Unterstriche in Titeln nicht erlabt?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 4325790645
Url: https://administrator.de/contentid/4325790645
Printed on: April 19, 2024 at 23:04 o'clock
4 Comments
Latest comment
Hi,
Alternativ kannst Du auch über "Sicherungsfähige Elemente" gehen, die Datenbank auswählen und explizit das Recht "Tabellen erstellen" erteilen.
E.
sie erstellt Tablelen (ddladmin)
Dafür.Alternativ kannst Du auch über "Sicherungsfähige Elemente" gehen, die Datenbank auswählen und explizit das Recht "Tabellen erstellen" erteilen.
E.
1
moin, das ist es nicht. Tabellen und Stored Procedures erstellen kann sie mit db_ddladmin
Das Datenimporttool fängt den Fehler nicht ab, die Applikation selbst bringt mir bei dem Vorgang ein "Execute permission was denied, der Profiler aber sagt mir "RPC completed."
Das Datenimporttool fängt den Fehler nicht ab, die Applikation selbst bringt mir bei dem Vorgang ein "Execute permission was denied, der Profiler aber sagt mir "RPC completed."
Hallo,
klingt seltsam. Wenn es ein Rechteproblem wäre, dann kommt normalerweise eine Meldung, daß Du dieses oder jenes nicht darfst, weil Dir die Rechte fehlen.
Was hast Du denn im Profiler eingestellt zur Protokollierung? Ich würde mal SP:StmtStarting und SP:StmtCompleted empfehlen. Ggf. auch noch für TSQL, also SQL:... Achja und natürlich die User Error Message.
Was meint der Aktivitätsmonitor, was in dem Moment noch passiert?
Und was setzt Ihr für einen SQL Server ein? Sind die CU einigermaßen aktuell?
Gruß, Mad Max
klingt seltsam. Wenn es ein Rechteproblem wäre, dann kommt normalerweise eine Meldung, daß Du dieses oder jenes nicht darfst, weil Dir die Rechte fehlen.
Was hast Du denn im Profiler eingestellt zur Protokollierung? Ich würde mal SP:StmtStarting und SP:StmtCompleted empfehlen. Ggf. auch noch für TSQL, also SQL:... Achja und natürlich die User Error Message.
Was meint der Aktivitätsmonitor, was in dem Moment noch passiert?
Und was setzt Ihr für einen SQL Server ein? Sind die CU einigermaßen aktuell?
Gruß, Mad Max
Die Lösung ist
grant execute on schema::dbo to sqlbenutzername;
Hi, ein anderer Teil der Applikation hat dafür eine Fehlerbehandlung gehabt, die mir sagte daß eine EXECUTE permission fehlt.
Das Datenim/Exporttool der Applikation ist einfach vom Bildschirm verschwunden, über die applikation.exe.config hab ich dann das Errorlevel auf Verbose gesetzt und hatte einen Callstack bzw eine Fehlermeldung im Debugview die nicht mehr auf einem 2,5K bildschirm paßt.
Im Profiler hatte ich ein RPC completed, einziges Indiz ist daß da scheinbar nichts passsiert ist sind die Nullen bei CPU / reads/writes/duration. Dieser Typ stored proceudre ansonsten ein paar SQL Befehle aus die typischerweise 20 bis 100 ms Laufzeit haben. Daß dabei ein Fehler aufgetreten ist protokolliert der SQL Server aufgrund der Standard-Traceflags nicht mit, nicht mal mit dem C2 Auditing. Man müßte wissen was das für eine Exception ist und einen custom Trace dafür aktivieren, damit man das hinterher mit im SQL Server Log hat... auch im Windows Ereignisprotokoll findet man nichts
Und "access denied" Fehler protokolliert der SQL Server standardmäßig nicht mit es sei denn man sagt ihm das daß er das tun soll:
exec dbo.sp_altermessage 229, 'WITH_LOG', 'true';
Es gibt noch andere Fehlercodes... aber mit diesem Mod steht im SQL Server auch ein "Access denied on xxxxx"
Aus irgendwelchen Gründen ist das execute für eine Stored procedure nicht in den Rollen enthalten die eigentlich eine Teilmenge des db_owner sein sollten. Haben sie wohl vergessen denn das was man bei MS findet ist nur "db_owner kann ein drop database auf die eigene Datenbank ausführen" aber daß es auch die einzige Rolle ist die implizit exec proc hat... stand bei Microsoft nicht.
Nachdem ich seit 1999 beruflich den MS SQL Server in fast allen Versionen betreut habe ist das bisher das einzige kleinere Problemchen, gepaart mit dieser idiotischen Schema-Simulation und der Unterlassung des SSMS ein dbo als Standardschema beim Berechtigunen von Windows Usern einzutragen...
Bevor ich bei meinem aktuellen Brötchengeber angeheuert hatte schrieb der seinen Kunden sogar vor, die Software als sysadm auf die Datenbank zugreifen zu lassen
weil sie vorher überhaupt keinen Datenbankspezialisten hatten. Aber auch der db_owner ist schon öfters mal hinterfragt worden nur jetzt haben wir den ersten Deal den wir nur gewinnen können wenn wir auf den db_owner verzichten können.
grant execute on schema::dbo to sqlbenutzername;
Hi, ein anderer Teil der Applikation hat dafür eine Fehlerbehandlung gehabt, die mir sagte daß eine EXECUTE permission fehlt.
Das Datenim/Exporttool der Applikation ist einfach vom Bildschirm verschwunden, über die applikation.exe.config hab ich dann das Errorlevel auf Verbose gesetzt und hatte einen Callstack bzw eine Fehlermeldung im Debugview die nicht mehr auf einem 2,5K bildschirm paßt.
Im Profiler hatte ich ein RPC completed, einziges Indiz ist daß da scheinbar nichts passsiert ist sind die Nullen bei CPU / reads/writes/duration. Dieser Typ stored proceudre ansonsten ein paar SQL Befehle aus die typischerweise 20 bis 100 ms Laufzeit haben. Daß dabei ein Fehler aufgetreten ist protokolliert der SQL Server aufgrund der Standard-Traceflags nicht mit, nicht mal mit dem C2 Auditing. Man müßte wissen was das für eine Exception ist und einen custom Trace dafür aktivieren, damit man das hinterher mit im SQL Server Log hat... auch im Windows Ereignisprotokoll findet man nichts
Und "access denied" Fehler protokolliert der SQL Server standardmäßig nicht mit es sei denn man sagt ihm das daß er das tun soll:
exec dbo.sp_altermessage 229, 'WITH_LOG', 'true';
Es gibt noch andere Fehlercodes... aber mit diesem Mod steht im SQL Server auch ein "Access denied on xxxxx"
Aus irgendwelchen Gründen ist das execute für eine Stored procedure nicht in den Rollen enthalten die eigentlich eine Teilmenge des db_owner sein sollten. Haben sie wohl vergessen denn das was man bei MS findet ist nur "db_owner kann ein drop database auf die eigene Datenbank ausführen" aber daß es auch die einzige Rolle ist die implizit exec proc hat... stand bei Microsoft nicht.
Nachdem ich seit 1999 beruflich den MS SQL Server in fast allen Versionen betreut habe ist das bisher das einzige kleinere Problemchen, gepaart mit dieser idiotischen Schema-Simulation und der Unterlassung des SSMS ein dbo als Standardschema beim Berechtigunen von Windows Usern einzutragen...
Bevor ich bei meinem aktuellen Brötchengeber angeheuert hatte schrieb der seinen Kunden sogar vor, die Software als sysadm auf die Datenbank zugreifen zu lassen
weil sie vorher überhaupt keinen Datenbankspezialisten hatten. Aber auch der db_owner ist schon öfters mal hinterfragt worden nur jetzt haben wir den ersten Deal den wir nur gewinnen können wenn wir auf den db_owner verzichten können.1
