J'ai une base de données SQL Server 2005 à laquelle j'essaie d'accéder en tant que compte d'utilisateur limité, en utilisant l'authentification Windows. J'ai BUILTIN \ Users ajouté en tant qu'utilisateur de base de données (avant que je l'ai fait, je ne pouvais même pas ouvrir la base de données). Je travaille sous l'hypothèse que tout le monde est censé avoir des permissions pour le rôle «public» qui leur est appliqué, donc je n'ai rien fait avec l'attribution de rôle. Sous tblFoo, je peux utiliser la boîte de dialogue Propriétés SSMS (page Permissions) pour ajouter "public", puis définir les permissions explicites. Parmi ceux-ci est "Grant" pour SELECT. Mais en cours d'exécutionLe rôle de base de données "public" SQL Server 2005 ne semble pas s'appliquer?
SELECT * from tblFoo;
comme un compte limité (Utilisateurs BUILTIN \) me donne une erreur "Sélectionner l'autorisation refusée sur l'objet 'tblFoo', 'bar' base de données, schéma 'dbo'". Dans la boîte de dialogue des propriétés, il y a un bouton "Autorisations effectives", mais il est grisé
En outre, j'ai essayé de créer un compte non-privé appelé "UserTest", en ajoutant cela au niveau du serveur, puis en le mappant vers le " Cela m'a permis d'ajouter UserTest à la liste "Utilisateurs ou Rôles", ce qui m'a permis d'exécuter "Autorisations effectives" pour le compte, mais aucune autorisation ne figure dans la liste - cela ne semble pas correct. public, et les subventions publiques (entre autres) Sélectionnez sur tblFoo, alors pourquoi le compte UserTest ne montre-t-il pas une autorisation effective? Je me sens comme si je deviens un peu fou ici. les gens n'aiment pas utiliser le rôle «public» pour définir les permissions, c'est juste mon temps de bricolage, dans la conception finale je suis sûr que nous aurons plusieurs rôles de base de données flexibles (personnalisés). J'essaie juste de comprendre le comportement que je vois, alors s'il vous plaît ne "ne fais pas ça!" réponses. MISE À JOUR: Apparemment, je connais juste assez de SQL Server pour être un danger pour moi-même et pour les autres. En réglant les permissions (comme je l'ai dit, "entre autres"), j'ai eu DENY CONTROL. Quand j'ai mis cette permission, je pense que j'ai essayé de chercher ce qu'elle a fait, j'ai eu une vague idée, et j'ai décidé de refuser. Je ne peux pas me rappeler actuellement pourquoi cela semblait être la chose à faire, mais il semblerait que c'était la raison pour laquelle je recevais des échecs de permission. Donc, je suis en train de mettre à jour ma question: quelqu'un peut-il expliquer l'autorisation "CONTROL", en ce qui concerne les tables?
OK, donc pour être clair: * Si je GRANT contrôle, ils peuvent faire quelque chose avec la table * Si je le renierai contrôle, ils sont interdits de faire quelque chose avec la table * Donc, si je veux sélectivement accorder ou refuser d'autres autorisations (mise à jour, insérer, etc), je devrais REVOKE le contrôle Est-ce exact? – Coderer
oui. REVOKE supprime le GRANT ou DENY (qui est explicite). Cependant, vous accorderiez généralement juste une combinaison de SELECT, INSERT, UPDATE, DELETE ou EXEC ... c'est assez pour 99% + d'applications. CONTROL accorde trop de droits (par exemple, changer la table ou changer la sécurité). – gbn