Discussion :

[dngaya]

Bonjour,
Je voudrais créer une procedure stockée pour un utilisateur qui n'a que les droits de select sur tous les objets de la base de données. mon problème est de faire à ce que ce dernier ne modifie pas directement les objets mais plutôt passe par une procedure stockée. Mais j'ai une erreur lorsque cet utilisateur qui a ldroit d'execute sur la procedure stockée test sur la base data1 et lors de l'execution de la proc. , il reçoit le message d'erreur suivant:

SQL Server Message: UPDATE permission denied on object IRPT, data2, owner dbo (sev 14, MsgNo 10330, lineNo 62)

data2 est la deuxième base du dataserver.

Voici ci-dessous le script qui a été lancé:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
use data1
go
 
declare @att varchar(255), @id int
 
select @att = "Type de maquette RI"
 
select @id = idBRC_Attribut from data2..test where c80Libelle_Etiquette = @att
 
create table #listeValeur (c80Libelle_Etiquette varchar(80))
 
insert into #listeValeur select "AA ABS Return NF 343"
 
 
exec proctest @id,null,null,null
go

L'objet IRP se trouve dans la base data2.


Que ce qui pose problème dans ce script ? comment faire pour que la procedure s'execute avec la mise à jour des objets sans pour autant donner explicitement les privilèges aux utilisateurs ?
Merci de vos conseils.

[mpeppler]

Bienvenu dans le monde merveilleux de la "concrete authentication" de Sybase...

Voici les règles:

1. Si on a le droit d'exécuter une proc, on peut lire/ecrire les tables que cette proc utilise dans la même database

2. Si le DBO de deux bases est le même, et que tous les objets référencés ont été créé avec le VRAI dbo (donc pas un user aliasé dbo, comme par example "sa" si la base appartient à "tartampion"), alors on pourra aussi accèder à ces tables dans l'autre database.

Donc - ton problème est soit que les deux databases n'ont pas le même DBO, soit que certains objets référencés ont été créé avec un login qui n'est pas le vrai DBO. Ce dernier point peut être vérifé via la colonne "login" de la table sysobjects - cette colonne est NULL si l'objet a été créé avec le vrai DBO de la database.

Michael