Re: nocht dbo-Besitzer verhindert Zugriff
- From: "Uwe Ricken" <spam@xxxxxxxxxxxxx>
- Date: Mon, 26 Nov 2007 07:59:07 +0100
Hallo Andy,
War das nun eine Todsünde oder ist das noch im Rahmen des "erlaubten"? Bin etwas unsicher, da ja die Rolle "db_owner" schon ziemlich mächtig ist (laut Doku: "Verfügt über alle Berechtigungen in der Datenbank.")! Gibt es noch eine andere Lösung bei Verwendung des SQL-Server 2000??? Oder als Alternative eine Rolle, die wiederum auf Tabellen eines anderen Besitzers zugreifen darf? Bin hier total am rotieren und finde einfach keine Lösung... ;-(
unabhängig von der Sinnlosigkeit dieses Konzepts (der Autor Eurer Anwendung kennt wohl noch nicht einmal die Grundlagen eines RDBMS-Systems) ist eine andere als die von Dir beschriebene Lösung nicht möglich.
Aufgrund der Tatsache, dass Objekte im Kontext des dbo erstellt werden sollen, wird also eine Mitgliedschaft in der Gruppe db_owner zwingend erforderlich, wenn die Benutzer selbst nicht Admins auf dem SQL-Server sind!
Ansonsten müßtest Du IMMER wissen, wer der Eigentümer der erstellten Relation ist.
Das wäre ein logistischer Aufwand, der wohl in keinem Verhältnis zum Ergebnis stünde, oder?
Beispiel:
User A (Gruppe public, Recht: CREATE TABLE)
Erstellt der Benutzer eine Tabelle, kann er sie nur in seinem Kontext erstellen:
user_a.tblBereich001
Script für Trigger:
EXEC ('CREATE TABLE tblBereich001 (....))
-- Berechtigungen für alle user
EXEC ('GRANT ALL ON tblBereich001 TO public')
User B (Gruppe public, Recht: CREATE TABLE)
user_b.tblBereich002
* Script siehe oben
Das Problem hierbei ist nun, dass nur über Abfrage der Relation dbo.sysObjects herausbekommen kannst, wer der Eigentümer der Relation ist.
Zum Beispiel so:
Daten würden nun über eine Stored Procedure an den Client zurückgeliefert werden
CREATE PROC proc_app_GetBereichData
@BereichId int
AS
SET NOCOUNT ON
DECLARE @ObjectId int
DECLARE @TableName varchar(100)
DECLARE @stmt varchar(1000)
SET @TableName = 'tblBereich' + CONVERT(varchar, @BereichId)
SET @ObjectId = OBJECT_ID(@TableName)
IF (@ObjectId IS NULL)
RETURN
SET @stmt = 'SELECT * FROM ' + u.name + '.' + o.name + ' FROM dbo.sysusers u INNER JOIN dbo.sysObjects o ON (u.uid = o.uid) WHERE o.Id = ' + CONVERT(varchar, @ObjectId)
-- So, nun hast Du das Basis-Statement für die Ermittlung Deiner Daten
-- Mal sehen, was in der Tabelle steht
EXEC (@stmt)
SET NOCOUNT OFF
GO
-- Berechtigungen für alle (geht ja auch nicht anders)
GRANT EXECUTE ON dbo.proc_app_GetBereichData TO public
-- Aufruf
EXEC dbo.proc_app_GetBereichData 1
Von daher wirst Du wohl oder übel mit diesem Konstrukt leben müssen bis Ihr ev. mal 2005 / 2008 bekommt ;-)
HTH ;-)
--
Gruß, Uwe Ricken
MCP for SQL Server 2000 Database Implementation
db-Berater GmbH - 64390 Erzhausen
http://www.db-berater.de
http://www.memberadmin.de
http://www.conferenceadmin.de
____________________________________________________
dbdev: http://www.dbdev.org
FAQ: http://www.donkarl.com/AccessFAQ.htm
.
- Follow-Ups:
- Re: nocht dbo-Besitzer verhindert Zugriff
- From: Andy Dorwald
- Re: nocht dbo-Besitzer verhindert Zugriff
- References:
- nocht dbo-Besitzer verhindert Zugriff
- From: Andy Dorwald
- Re: nocht dbo-Besitzer verhindert Zugriff
- From: Olaf Pietsch
- Re: nocht dbo-Besitzer verhindert Zugriff
- From: Andy Dorwald
- Re: nocht dbo-Besitzer verhindert Zugriff
- From: Olaf Pietsch
- Re: nocht dbo-Besitzer verhindert Zugriff
- From: Andy Dorwald
- nocht dbo-Besitzer verhindert Zugriff
- Prev by Date: Re: nocht dbo-Besitzer verhindert Zugriff
- Next by Date: Re: div. Fehlermeldungen in Ereignisanzeige
- Previous by thread: Re: nocht dbo-Besitzer verhindert Zugriff
- Next by thread: Re: nocht dbo-Besitzer verhindert Zugriff
- Index(es):
Relevant Pages
|