> Tech > Les liens des chaînes de propriété

Les liens des chaînes de propriété

Tech - Par iTPro - Publié le 24 juin 2010
email

SQL Server identifie les propriétaires d'objets par leur SID (security ID) - et pas par leur nom d'utilisateur - dans les chaînes de propriété. Comme le SID est le lien dans la chaîne de propriété, on peut considérer que les objets appartiennent aux logins SQL Server plutôt qu'aux utilisateurs de

Les liens des chaînes de propriété

la
base de données.

La subtile différence entre le nom
d’utilisateur et le SID importe peu dans
le cas de chaînes de propriété intra-base
de données, parce que chaque propriétaire
d’objet (utilisateur de la base de
données) est associé à  un login. De ce
fait, tous les objets qu’un utilisateur
possède dans une base de données
unique sont toujours associés au même
SID. En revanche, s’il y a plusieurs bases
de données, il faut considérer que les
utilisateurs qui ont le même nom dans
des bases de données différentes peuvent
être associés à  des logins différents.
Quand les différents logins apparaissent
dans la chaîne de propriété,
celle-ci est cassée. Par ailleurs, un login
peut fort bien être associé à  différents
noms d’utilisateurs dans différentes
bases de données. Une telle situation ne
casse pas la chaîne de propriété bien
que les noms des propriétaires d’objets
soient différents.

Le code du listing 1 montre l’importance
des SID dans les chaînes de
propriété inter-base de données. Le
script crée deux bases de données,
Database1 et Database2, appartenant
aux logins DatabaseOwner1 et
DatabaseOwner2, respectivement.
View [Database2].[dbo].[MyView] référence
la table [Database1].[dbo].
[MyTable] et au rôle public, j’ai accordé
des permissions SELECT sur la vue
mais pas sur la table. Le code essaie
alors de sélectionner dans la vue sous
le contexte de sécurité utilisateur
guest.

La chaîne de propriété apparaît
d’abord non cassée parce que les propriétaires
de la table et de la vue sont
tous deux DBO. Cependant, les utilisateurs
DBO sont associés à  différents logins.
Par conséquent, les SID des propriétaires
d’objets sont différents et la
chaîne de propriété inter-base de données
est cassée. Résultat : la première
instruction SELECT bute sur une erreur
de permission, parce que l’utilisateur
n’a pas de permission SELECT sur
la table.

Quand la propriété de la base de
données change de telle sorte que le
même login (DatabaseOwner1) possède
les deux bases de données, l’instruction
SELECT réussit bien que l’utilisateur
n’ait pas la permission
d’accéder directement à  la table. La
chaîne de propriété reste intacte dans
ce cas parce que l’utilisateur DBO dans
chaque base de données est associé au
même login. SQL Server Books Online
(BOL) n’est pas clair quant à  l’importance
de la propriété de la base de données
dans les chaînes de propriété inter-
base de données. Pour avoir une
explication plus claire et plus détaillée
sur la manière dont SQL Server détermine
s’il faut vérifier les permissions,
voir l’article Microsoft « INF: Object
Ownership Chain Checking Across
Databases Depends on Database
Ownership » à  http://support.microsoft.
com/default.aspx?scid=kb;en-us;q272424.

Notons que j’ai inclus la commande
SETUSER dans le script pour
illustrer le comportement des chaînes
de propriété sur plusieurs bases de
données. SETUSER permet à  un DBA
de tester la sécurité par une connexion
base de données unique, mais la commande
est incluse dans SQL Server
2000 et 7.0 pour la rétro-compatibilité
uniquement. Il ne faut pas utiliser SETUSER
en code de production parce
que le comportement de la commande
pourrait changer dans les futures releases
ou packs de service de SQL
Server. Vous pouvez obtenir le même
résultat sans SETUSER en exécutant les
instructions SELECT quand vous êtes connecté comme n’importe quel utilisateur
non-sa autre que Database-
Owner1. Vous ne pouvez pas utiliser le
login DatabaseOwner1 pour tester la
sécurité parce que il a des permissions
complètes sur tous les objets
Database1. De même, le login sa est le
DBO dans toutes les bases de données
et a des permissions complètes sur
tous les objets.

Pour qu’une chaîne de propriété
inter-base de données reste intacte, il
faut que les propriétaires d’objets dans
les différentes bases de données soient
associés au même login. Pour obtenir
un rapport qui montre l’association
entre les logins et les utilisateurs, vous
pouvez exécuter la procédure stockée système sp_helpuser dans chaque base
de données.

Vous pouvez utiliser la procédure
stockée système sp_changedbowner
pour changer la propriété de la base de
données afin que tous les objets appartenant
au DBO dans les bases de données
impliquées dans la chaîne, correspondent
au même SID login. En
utilisant sp_changedbowner, vous risquez
d’obtenir l’erreur ambiguà« 15110,
The proposed new database owner is
already a user in the database, si SQL
Server détecte une non-concordance
entre le SID DBO enregistré dans les
tables système sysdatabases et sysusers.
Une telle non-concordance pourrait
survenir si quelqu’un d’autre que
le propriétaire original restaurait la
base de données. La colonne SID dans
sysdatabases montre l’utilisateur qui a
restauré la base de données, mais le
SID DBO dans la table sysusers
contient encore le propriétaire d’origine.

Il est facile de corriger une nonconcordance
de SID. Le script du listing
2 change temporairement la propriété
de la base de données en un
login concordant (TempOwner) qui
synchronise le DBO dans les tables sysdatabases
et sysusers. On peut ensuite
changer le DBO avec le login souhaité
(sa).

Téléchargez gratuitement cette ressource

TOP 5 Modernisation & Sécurité des Postes Clients

TOP 5 Modernisation & Sécurité des Postes Clients

Pour aider les entreprises à allier les restrictions liées à la crise et la nécessaire modernisation de leurs outils pour gagner en réactivité, souplesse et sécurité, DIB-France lance une nouvelle offre « Cloud-In-One » combinant simplement IaaS et DaaS dans le Cloud, de façon augmentée.

Tech - Par iTPro - Publié le 24 juin 2010